Methods and apparatuses for contention-based message handling

Abstract

A UE is disclosed, the UE comprising: at least one processor; and at least one memory storing instructions that, when executed by the at least one processor, cause the first apparatus UE at least to perform: transmitting a contention-based message to a network entity; receiving a response indicative of an unsuccessful contention resolution for the UE; determining whether to retransmit the contention-based message or to fallback to transmitting a random access preamble; based on the determining, retransmitting the contention-based message or transmitting the random access preamble; wherein the instructions, when executed by the at least one processor, further cause the apparatus UE to perform at least one of (i) or (ii) : (i) obtaining information relating to a fallback ratio; and wherein the determining whether to retransmit the contention-based message or to fallback to transmitting a random access preamble is based on the fallback ratio; or (ii) if it is determined to fallback to transmitting the random access preamble, determining a backoff time for transmitting the random access preamble based on a probability distribution of possible candidate backoff time values; and transmitting the random access preamble based on the determined backoff time. Further, a network entity, a system and corresponding methods are disclosed.

Description

METHODS AND APPARATUSES FOR CONTENTION-BASED MESSAGE HANDLING

[0001] FIELD OF DISCLOSURE

[0002] The following disclosure relates to the field of communication technology, in particular communication networks, in particular wireless communication networks. The disclosure may for example relate to an apparatus, a method, a computer program, a computer readable medium, and a system for handling contention-based messages.BACKGROUND

[0003] In mobile communication networks, a contention-based message may be transmitted by user equipment (UE) , for example during a random access procedure. The purpose of transmitting the contention-based message may be to gain network access and / or to establish synchronization with the network. The contention-based nature of this message means that multiple UEs may transmit on the same time / frequency resources, which may lead to collisions. In such cases, contention resolution may fail for at least some of the UEs that transmitted on the same time / frequency resources.

[0004] How to handle such situations efficiently may pose challenges in some scenarios.

[0005] SUMMARY OF SOME EXAMPLE EMBODIMENTS

[0006] According to an embodiment, the following is disclosed:

[0007] A user equipment, UE, comprising:

[0008] at least one processor; and

[0009] at least one memory storing instructions that, when executed by the at least one processor, cause the UE at least to perform:

[0010] transmitting a contention-based message to a network entity;

[0011] receiving a response indicative of an unsuccessful contention resolution for the UE;

[0012] determining whether to retransmit the contention-based message or to fallback to transmitting a random access preamble;

[0013] based on the determining, retransmitting the contention-based message or transmitting the random access preamble;

[0014] wherein the instructions, when executed by the at least one processor, further cause the UE to perform at least one of (i) or (ii) :

[0015] (i) obtaining information relating to a fallback ratio; and

[0016] wherein the determining whether to retransmit the contention-based message or to fallback to transmitting a random access preamble is based on the fallback ratio; or

[0017] (ii) if it is determined to fallback to transmitting the random access preamble, determining a backoff time for transmitting the random access preamble based on a probability distribution of candidate backoff time values; and

[0018] transmitting the random access preamble based on the determined backoff time.

[0019] Furthermore, the following is disclosed:

[0020] A network entity comprising:

[0021] at least one processor; and

[0022] at least one memory storing instructions that, when executed by the at least one processor, cause the network entity at least to perform:

[0023] receiving, from a plurality of UEs, a plurality of contention-based messages;

[0024] transmitting a response indicative of an unsuccessful contention resolution for at least some UEs of the plurality of UEs;

[0025] wherein the instructions, when executed by the at least one processor, further cause the network entity to perform at least one of (i) or (ii) :

[0026] (i) transmitting information relating to a fallback ratio to control a ratio of the at least some UEs that retransmit a contention-based message and to control a ratio of the at least some UEs that fallback to transmitting a random access preamble; or

[0027] (ii) transmitting a backoff indicator, the backoff indicator being associated with candidate backoff time values for allowing one or more of the at least some UEs to respectively determine, based on a probability distribution of the candidate backoff time values, a backoff time for transmitting a random access preamble.

[0028] Whenever it is referred to a UE or a network entity, it is to be understood that this is merely an example for an apparatus and that any apparatus may have the described functionality.

[0029] Any disclosure herein relating to any example aspect is to be understood to be equally disclosed with respect to any subject-matter according to the respective example aspect, e.g. relating to an apparatus, a method, a computer program, and a computer-readable medium. For example, any passage describing at least one processor; and at least one memory including instructions; the at least one memory and the instructions configured to, with the at least one processor, cause an apparatus at least to perform a step is to be understood as disclosing the step as a method step itself. The same holds the other way around, i.e., any passage describing a method or method step is to be understood as disclosing that at least one processor; and at least one memory including instructions; the at least one memory and the instructions configured to, with the at least one processor, cause an apparatus at least to perform the method or method step. The disclosure of a method or a method step shall also be considered as a disclosure of means for performing and / or causing to perform the respective method or method step. Likewise, the disclosure of means for performing and / or causing to perform a method or method step shall also be considered as a disclosure of the method or method step itself.

[0030] Specifically, an apparatus (e.g., a network entity or UE) is disclosed, configured to carry out, perform and / or control or comprising respective means for performing and / or controlling the method according to any of the above-mentioned example aspects. According to a further example aspect, an apparatus (e.g., a UE or network entity) is disclosed comprising at least one processor; and at least one memory storing instructions that, when executed by the at least one processor, cause the apparatus at least to perform the method according to any aspect.

[0031] The apparatus (e.g., UE or network entity) according to any aspect may comprise means for performing the specified method or steps.

[0032] The disclosed apparatus according to any aspect may comprise only (i.e., consist of) the disclosed components, for instance means, processor, memory, circuitry, or may further comprise one or more additional components.

[0033] The means may be implemented in hardware and / or software. They may comprise for instance at least one processor for executing processor instructions for performing the required functions, at least one memory storing the instructions, or both. Alternatively, they could comprise for instance circuitry that is designed or configured to implement the required functions, for instance implemented in a chipset or a chip, like an integrated circuit. In general, the means may comprise for instance one or more processing means or processors.

[0034] As used in this application, the term “circuitry” may refer to one or more or all of the following:

[0035] (a) hardware-only circuit implementations (such as implementations in only analog, and / or digital and / or quantum circuitry) and

[0036] (b) combinations of hardware circuit (s) and software, such as (as applicable) :

[0037] (i) a combination of analog, digital and / or quantum hardware circuit (s) with software / firmware and

[0038] (ii) any or all portions of hardware processor (s) (including digital and / or quantum processor (s) ) with software, and memory (ies) that work together to cause an apparatus, such as a mobile device, computing device, or server, to perform various functions) and

[0039] (c) any or all portions of hardware circuit (s) , such as microprocessor (s) , processor (s) and / or quantum processor (s) , that requires software (e.g., firmware) for operation, but the software may not be present when it is not needed for operation.

[0040] This definition of circuitry applies to all uses of this term in this application, including in any claims. As a further example, as used in this application, the term circuitry also covers an implementation of merely a hardware circuit or processor (or multiple processors) or portion of a hardware circuit or processor and its (or their) accompanying software and / or firmware. The term circuitry also covers, for example and if applicable to the particular claim element, a baseband integrated circuit or processor integrated circuit for a mobile device or a similar integrated circuit in server, a cellular network device, or other computing or network device.

[0041] A UE may be an apparatus that allows a user or an application access to network services. For example, a UE may be a cell phone, smartphone, tablet, laptop, TV, a vehicle, a narrowband Internet of Things (NB-IoT) device or IoT-device. The link between the UE and the network may be a radio link.

[0042] A network entity may be a network entity of a network (e.g., communications network) , for instance a TRP, a eNodeB, a gNB, a RAN node, a base station, or part thereof. A network entity may be logically and / or physically distributed.

[0043] Further, a computer program product is disclosed, the computer program product when executed by a processor of an apparatus (e.g., a UE) causing said apparatus to perform a method according to any example aspect.

[0044] Moreover, a computer program is disclosed, the computer program when executed by a processor causing one or more apparatuses, for instance a UE or network entity, to perform and / or control the actions of the method according to any example aspect.

[0045] Additionally, a computer readable storage medium (e.g. tangible and / or non-transitory) is disclosed, the computer readable storage medium comprising at least one of the disclosed computer program products or computer programs.

[0046] Furthermore, a system is disclosed. The system may comprise at least one of the following: one or more UE (e.g., a plurality of UEs) and one or more network entities.

[0047] In the following, example features and example embodiments of all aspects will be described in further detail.

[0048] In various embodiments, a UE transmits a contention-based message, e.g., using an uplink channel, for instance, to a network entity.

[0049] A contention-based message may be a message transmitted by a user UE in a mobile communication network that may potentially collide with messages from other UEs due to the use of time-frequency resources that may also be used by other UEs. The message may be used to request access to and / or synchronization with a network resource.

[0050] The contention-based message may comprise information that allows distinguishing the UE from other UEs. Such information may be an identifier that is, e.g., permanently or temporarily associated with the UE.

[0051] The contention-based message may comprise uplink data. This may be done as part of an Early Data Transmission (EDT) . It may allow reducing latency since the UE does not need to wait until access to the network resource and / or synchronization with the network resource has been confirmed. Small data transmission (SDT) is another procedure which allows to transmit small amounts of data without UE transitioning to a connected state. In this application, embodiments have been described in the context of EDT, but can be applied in the context of SDT as well.

[0052] An example of a contention-based message is a contention-based msg3 (message 3 or Msg3) . The term msg3 comes from a 4-step random access procedure where msg3 referred to the third message. In the 4-step random access procedure, the UE can first transmit a random access preamble to the network. The network can transmit a random access response (RAR) , scheduling resources for a msg3 by the UE. The UE may then transmit the msg3. The network may reply with a msg4.

[0053] However, it is to be understood that msg3 is a message that is not only used in this context. Rather, a msg3 may be transmitted in different procedures and contexts. In particular, it need not be a third transmitted message. For example, in various embodiments, the msg3 can directly be transmitted as contention-based msg3 without first transmitting a random access preamble to the network and waiting for a RAR. Across the network, this may allow reducing the average latency.

[0054] Another example for a contention-based message is msgA. MsgA may refer to a message transmitted by a user equipment (UE) in a two-step random access procedure, e.g., in a New Radio (NR) system. MsgA may be transmitted without a prior uplink grant. MsgA may include a preamble sequence and a payload. The preamble may be selected from a set of contention-based preambles. The payload may carry a MAC PDU and / or an RRC message. The structure of MsgA may follow configuration parameters provided by system information and / or dedicated signaling. The MAC PDU in MsgA may include a temporary identifier and / or a scheduling request. The RRC message may include an RRC setup request and / or UE capability information. The base station may process MsgA to derive timing information and / or identify the UE. MsgA reception may trigger the generation of MsgB by the base station.

[0055] The contention-based message may be transmitted using an uplink channel. The uplink channel may be an uplink shared channel. For instance, the uplink channel may be an Uplink Shared Channel (UL-SCH) and / or a Physical Uplink Shared Channel (PUSCH) or a narrowband PUSCH (NPUSCH) . The uplink channel may be distinguished from other types of channels, e.g., random access channel (RACH) . Transmitting the contention-based message using an uplink channel may mean that at least part of the contention-based message is transmitted in an uplink channel. For example, msg3 may be transmitted using UL-SCH or PUSCH or NPUSCH. MsgA may be transmitted using PUSCH.

[0056] In various scenarios, the UE receives a response indicative of an unsuccessful contention resolution for the UE.

[0057] The response may comprise information that allows the UE to determine whether the contention resolution was successful. A pre-defined rule may be used for that.

[0058] For example, the response may comprise a UE Contention Resolution Identity. The UE Contention Resolution Identity may be compared with information transmitted in the contention based message (e.g., Common Control Channel (CCCH) Service Data Unit (SDU) ) . If, according to a pre-defined rule, there is a match between the information in the response and the information transmitted in the contention-based message, the response is indicative of a successful contention resolution. For example, the UE Contention Resolution Identity may correspond to the first 48 bits of the CCCH SDU.

[0059] As a further example, the information may be that the response is addressed to an identifier (e.g., Cell Radio-Network Temporary Identifier (C-RNTI) ) that is associated with the UE and / or was included in the contention-based message. If that is the case, in some embodiments, the response is indicative of a successful contention resolution.

[0060] There may be one or more conditions and if they are met, the UE may conclude that the response is indicative of a successful contention resolution. If none of these conditions is met or not all, the response may be indicative of an unsuccessful contention resolution for the UE.

[0061] Additionally or alternatively, there may be one or more conditions that indicate an unsuccessful contention resolution if met. Thus, if any one of these conditions is met, the response may be indicative of an unsuccessful contention resolution for the UE.

[0062] The response may be a msg4 or a msgB.

[0063] Given that the response is indicative of an unsuccessful contention resolution for the UE, the UE has likely not achieved its goal, e.g., synchronization with the network and / or access to a network resource and / or transfer of data. Thus, it may be useful for the UE to determine next steps.

[0064] The UE may determine whether to retransmit the contention-based message or to fallback to transmitting a (e.g., contention-based) random access preamble (which may be transmitted on a RACH) and, based on the determining, retransmit the contention-based message or transmitting the random access preamble.

[0065] In various embodiments, the UE may determine if to retransmit the contention-based message or if to fallback to transmitting a (e.g., contention-based) random access preamble (which may be transmitted on a RACH) and, based on the determining, retransmit the contention-based message or transmitting the random access preamble.

[0066] For example, if the UE determines to retransmit the contention-based message, it may retransmit the contention-based message, e.g., using an uplink channel. If the UE determines to fallback to transmitting a random access preamble, it may transmit the random access preamble.

[0067] The UE may be configured to determine one action out of a group of two actions, the two actions being (a) retransmitting the contention-based message and (b) falling back to transmitting a random access preamble, and perform the determined action.

[0068] In various embodiments, the random access preamble may transmitted using a random access channel, RACH. The random access preamble may transmitted using a physical random access channel, PRACH or a narrowband PRACH (NPRACH) . Transmitting the random access preamble may be part of (e.g., a first step of) a 4-step random access procedure. Transmitting the random access preamble may involve that the UE selects a random access preamble, e.g., from a plurality of candidate random access preambles.

[0069] In some embodiments, there may be a pre-defined rule according to which the UE determines whether to retransmit the contention-based message or to fallback to transmitting a random access preamble. For example, according to the pre-defined rule a UE may decide to retransmit the contention-based message a pre-determined number of times (e.g., only once) and, if contention resolution fails the pre-determined number of times, the UE decides to fallback to transmitting the random access preamble. In some embodiments, UE does not retransmit the contention-based message at all but always decides to fallback to transmitting the random access preamble. Alternatively, in some embodiments, the UE does not fallback to transmitting the random access preamble but continues retransmitting the contention-based message.

[0070] In some embodiments, the decision whether the UE is to retransmit the contention-based message or to fallback to transmitting a random access preamble is taken by the network. The network defines the condition under which the UE has to fallback to transmitting the random access preamble. The conditions and / or relevant information may be included in or implied by the response. For example, the UE may evaluate the condition, and determine based on the evaluation whether to retransmit the contention-based message or to fallback to transmitting a random access preamble. For example, the condition may be a reception of a fallback indication. The UE may determine whether to retransmit the contention-based message or to fallback to transmitting a random access preamble based on the response received from the network. For example, according to various embodiments, the response may comprise a fallback indication. The UE may determine to fallback to transmitting the random access preamble if the response comprises a fallback indication (and / or one or more further conditions are met) . Thus, the fallback may be network-controlled.

[0071] However, it can be observed that the process described above may lead to non-ideal situations. The reason is the contention-based nature of the message transmitted by the UE. It may occur that many UEs transmit a respective contention-based message so that the contention-based messages collide. Consequently, the response may indicate for many UEs that contention resolution failed. If many or even all UEs proceed to retransmitting a contention-based message, there is a comparatively high likelihood that the retransmitted contention-based messages will collide again, resulting in a similar situation as before. Similarly, if many UEs fallback to transmitting a random access preamble, they may all use a same preamble resource. This may result in collisions between the transmitted random access preambles and, thus, a similar situation as if all the UEs would retransmit the contention-based messages.

[0072] In view of these observations, there are different options. They may be applied separately or jointly.

[0073] According to a first option, the UE may obtain information relating to a fallback ratio, and the determining whether to retransmit the contention-based message or to fallback to transmitting a random access preamble may be based on the fallback ratio. The fallback ratio may be used in an attempt to make some UEs retransmit the contention-based message and make others fallback to transmitting the random access preamble. This can reduce the number of UEs transmitting contention-based messages in a resource for the contention-based messages, and reduce the number of UEs transmitting random access preambles in a preamble resource. As a result, the likelihood of collisions between the contention-based messages may be reduced and the likelihood of collisions between random access preambles may be reduced.

[0074] In various embodiments, the fallback ratio may be indicative of a probability with which the UE is statistically expected to fallback to transmitting the random access preamble. For example, the fallback ratio may not directly indicate for an individual UE whether it is to retransmit the contention-based message or whether it is to fallback to transmitting a random access preamble, e.g., in the form of a command directed to the UE. Rather, the fallback ratio may be a statistical measure. For instance, based on a fallback ratio, the UE may fallback to transmitting the random access preamble with a probability of x (e.g., 33%) and retransmit the contention-based message with a probability of (1-x) (e.g., 67%) . This principle may be effective for each of a plurality of UEs. As a result, statistically speaking, it can be expected that x of the UEs (e.g., 33%) will fallback to transmitting the random access preamble and (1-x) of the UEs (e.g., 67%) will retransmit the contention-based message. In this example, x may be the fallback ratio. Considering a group of UEs, the fallback ratio may indicate a ratio of the UEs that are statistically expected to fallback to transmitting the random access preamble. As the fallback ratio may relate to a probability, it is to be understood that in a single instance the actual ratio of UEs falling back to transmitting the random access preamble may differ from the statistically expected ratio.

[0075] In various embodiments, the information relating to the fallback ratio may be represented by reserved bits in a backoff indicator medium access control, MAC, subheader in the response. The backoff indicator MAC subheader may be similar to a backoff indicator MAC subheader usable in a random access response (RAR) . It may comprise one or more of an extension field (E, e.g., 1 bit) , a type field (T, e.g., 1 bit) , reserved bits (R, e.g., 2 bits) , and a backoff indicator field (BI, e.g., 4 bits) . The backoff indicator MAC subheader may be comprised in a MAC PDU.

[0076] In various embodiments, the information relating to the fallback ratio may be represented by a value in a backoff indicator field that is reserved for representing the fallback ratio. For example, the backoff indicator field may allow to indicate a plurality of values. A subset of the indicatable values may be reserved for representing the fallback ratio (and, by way of example, other values may be usable for indicating a backoff indicator) . For instance, 3 out of 15 indicatable values in the backoff indicator (BI) field may be reserved for indicating a fallback ratio (e.g., a fallback ratio of 1 / 4, 1 / 2, or 3 / 4) .

[0077] In various embodiments, the information relating to the fallback ratio may be comprised in a MAC control element (CE) in the response. MAC CE may refer to a fixed or variable-sized control structure included in a MAC PDU. A MAC CE may be used to convey control information between a UE and / or a base station. The MAC CE may be multiplexed with MAC SDUs and / or other MAC CEs in a single MAC PDU. The inclusion of a MAC CE in a MAC PDU may be determined by scheduling decisions and / or protocol requirements. The MAC CE payload may be processed by the MAC sublayer and / or passed to higher layers depending on the content. Transmission of MAC CEs may be prioritized over certain MAC SDUs and / or subject to specific transmission rules.

[0078] In various embodiments, the information relating to the fallback ratio may be comprised in a system information block (SIB) . The UE may obtain a SIB. SIB may refer to a structured unit of system information broadcast by a base station. A SIB may contain configuration parameters required by UE to access the network. A SIB may have a predefined format and / or content structure, e.g., as specified by the radio access technology. SIBs may be transmitted over a broadcast control channel and / or mapped to specific time-frequency resources. The scheduling of SIBs may be indicated in SIB1 and / or in the master information block (MIB) . UEs may decode SIBs during initial access and / or periodically while in connected or idle mode. Updates to SIBs may be signaled through modification periods and / or system information change notifications.

[0079] In various embodiments, the UE may obtain the information relating to the fallback ratio from the base station. For example, the information relating to the fallback ratio may be comprised in a Radio Resource Control (RRC) message. An RRC message may refer to a signaling message exchanged between UE and a base station for controlling radio resources. RRC messages may be used during connection establishment, reconfiguration, release, and / or mobility procedures. The RRC protocol may operate in idle and / or connected mode. An RRC message may carry configuration parameters for physical layer, MAC layer, and / or radio bearers. The message may include identifiers, timers, thresholds, and / or measurement configurations. RRC messages may be integrity protected and / or ciphered, depending on the security context. Each RRC message may belong to a specific message category, such as RRCSetup, RRCReconfiguration, and / or RRCRelease. RRC messages may be logged and / or analyzed for mobility management and / or troubleshooting.

[0080] In some embodiments, the UE may receive configuration information relating to the transmitting of the contention-based message using the uplink channel. The information relating to the fallback ratio may be comprised in the configuration information.

[0081] The configuration information may relate to the configuration of, e.g., CB-Msg3 transmission. The configuration may be or be comprised in system information. It may provide (e.g., cell-specific) uplink channel resources (e.g., PUSCH resources) for the transmission of the contention-based message.

[0082] When the fallback ratio has been obtained, there are different ways how the fallback ratio can be made effective at the UE.

[0083] In various embodiments, the determining, by the UE, whether to retransmit the contention-based message or to fallback to transmitting the random access preamble based on the fallback ratio may be further based on an identifier associated with the UE. The identifier may be or be representable by a number. It may be, e.g., an International Mobile Subscriber Identity (IMSI) of the UE. It can be assumed that, considering a large number of UEs, any digit may occur equally often in the identifiers of the UEs. By way of a very simplistic example, an identifier may have four binary digits, each digit being either 0 or 1. As an example, it can be expected that there are equally many UEs with an identifier whose last digit is 0 as there are UEs with an identifier whose last digit is 1. Thus, a fallback ratio of 50%may be achieved by having a UE check whether its identifier’s last digit is 0 and, if so, falling back to transmitting the random access preamble, and if the last digit is 1, retransmitting the contention-based message. Notably, this is a simplistic example and an implementation may be different and / or be more complex. For instance, the role of 0 and 1 may be reversed and / or a decimal or hexadecimal digit is considered and / or not the last but a first digit or any other (combination of) digit (s) is considered.

[0084] According to various embodiments, the determining whether to retransmit the contention-based message or to fallback to transmitting the random access preamble based on the fallback ratio and based on the identifier associated with the UE comprises:

[0085] applying, based on the fallback ratio, a modulo operation to the identifier associated with the UE; deciding, based on a result of the modulo operation and the fallback ratio, whether to retransmit the contention-based message or to fallback to transmitting the random access preamble.

[0086] For instance, UE may apply a modulo operation based on the denominator of the fallback ratio. For example, if the fallback ratio is 1 / 4, the UE may calculate {UE_ID mod 4 } . If the calculated result / value is less (or less or equal) to the numerator of the fallback ratio (e.g., 1 in the example) , then the UE fallbacks to transmitting the random access preamble, e.g., as part of 4-step random access channel (RACH) and / or EDT. In another example, if the fallback ratio is 3 / 4, then UE may use {UE_ID mod 4 } as well. If the result / value is less (or less or equal) to the numerator of the fallback ratio (e.g. 3 in this case) , then it may fallback to transmitting the random access preamble, e.g., as part of 4-step RACH and / or EDT.

[0087] Another way to implement the fallback ratio is based on a backoff time.

[0088] In various embodiments, the UE may determine, based on a probability distribution of candidate backoff time values, a backoff time associated with a potential retransmission of the contention-based message.

[0089] The backoff time may be determined as different values by different UEs. As a result, when multiple UEs determine different backoff times, the probability of further collisions may decrease.

[0090] The probability distribution may be, e.g., a uniform distribution. Thus, by way of example, each of the candidate backoff time values is equally probable. Other probability distributions are conceivable, e.g., a Gaussian distribution. The probability distribution may be pre-defined or configured by the network.

[0091] The candidate backoff time values may be a range of values, e.g., from a minimum to a maximum candidate backoff time value. Minimum and / or maximum candidate backoff time value (which may correspond to a backoff parameter value) may be pre-defined and / or configured and / or signaled by the network. In one example, the maximum candidate backoff time value is indicated by the network in the message 4, RRC or SIB.

[0092] For example, the candidate backoff time values may be values between 0 and 10 ms (e.g., integer values) and UE may draw one backoff time value randomly from the candidate backoff time values, e.g., 8 ms. Thus, the determining of one backoff time value may be based on randomly drawing a value from the candidate backoff time values.

[0093] The backoff time may be associated with a potential retransmission of the contention-based message in the sense that, if there is going to be a retransmission of the contention-based message, the backoff time may be used for a (next) retransmission, e.g., for delaying the retransmission of the contention-based message (e.g., of the same type) by the backoff time. This does not mean that there must be a retransmission of the contention-based message. Rather, the backoff time associated with a potential retransmission of the contention-based message may be determined before the UE has decided whether to retransmit the contention-based message or to fallback on transmitting a random access preamble. In various embodiments, the determining whether to retransmit the contention-based message or to fallback to transmitting the random access preamble based on the fallback ratio may comprise:

[0094] determining, based on the fallback ratio and the probability distribution of candidate backoff time values, a threshold;

[0095] comparing the determined backoff time associated with the potential retransmission of the contention-based message with the threshold; and

[0096] deciding whether to retransmit the contention-based message or to fallback to transmitting the random access preamble based on an outcome of the comparing of the determined backoff time associated with the potential retransmission of the contention-based message with the threshold.

[0097] The determining, based on the fallback ratio and the probability distribution of candidate backoff time values, a threshold may be done in such a way that a probability that the determined backoff time is below (or below or equal to) the threshold (essentially) corresponds to the fallback ratio (or, alternatively, that a probability that the determined backoff time is greater than (or greater than or equal to) the threshold (essentially) corresponds to the fallback ratio.

[0098] For example, the candidate backoff time values may be values between 0 and 10 ms (e.g., integer values) . The fallback ratio may be 3 / 4. The threshold may be determined as a product of the maximum of the backoff time values (e.g., 10 ms) and the fallback ratio (e.g., 3 / 4) , so that the threshold may be 7.5 ms.

[0099] As described above, by way of example, UE may draw one backoff time randomly from the candidate backoff time values, e.g., 8 ms. This backoff time may be compared with the threshold, e.g., comparing 8 ms with the threshold of 7.5 ms. By way of example, since the backoff time is above the threshold, the UE may decide to retransmit the contention-based message rather than falling back to transmitting the random access preamble.

[0100] Notably, the concept can be implemented in different ways. For example, the threshold may be determined as the maximum of the backoff time values (e.g., 10 ms) minus the product of the maximum and the fallback ratio (e.g., 7.5 ms) , so that the threshold is 2.5 ms. In that example, the UE may decide to retransmit the contention-based message only if the determined backoff time value is less than (or less than or equal to) 2.5 ms and otherwise fall back to transmitting the random access preamble.

[0101] In various embodiments, if it is determined to retransmit the contention-based message, the contention-based message may be retransmitted based on the determined backoff time associated with the potential retransmission of the contention-based message.

[0102] The candidate backoff time values may be dependent on and / or defined and / or characterized by a backoff indicator.

[0103] In various embodiments, the UE may obtain a backoff indicator for determining the backoff time associated with the potential retransmission of the contention-based message.

[0104] The backoff indicator may be associated with and / or characterize the candidate backoff time values, e.g., by specifying a minimum and / or a maximum backoff time value and / or a range of backoff time values. There may be pre-defined ranges and the backoff indicator can indicate one of the pre-defined ranges or there may be a pre-defined minimum or maximum and the backoff indicator may indicate the other end of the range.

[0105] In various embodiments, the backoff indicator is associated with (e.g., characterizes) the candidate backoff time values for determining the backoff time associated with the potential retransmission of the contention-based message by specifying an index to a look-up table, wherein the look-up table maps the index to a backoff parameter value, and wherein the candidate backoff time values are backoff time values that lie in a range between a pre-defined minimum backoff time value and the backoff parameter value.

[0106] The look-up table may be referred to as a BI table. It may comprise mappings of indexes to backoff parameter values. For example, there may be 13 different indexes (e.g., 0 to 12) mapped to 13 different backoff parameter values (e.g., 0ms, 10ms, 20ms, 30ms, 40ms, 60ms, 80ms, 120ms, 160ms, 240ms, 320ms, 480ms, 960 ms) . The look-up table may comprise different values in different embodiments and / or for different circumstances. For instance, the indexes may be mapped to different backoff parameter values for Narrowband-Internet of Things (NB-IoT) .

[0107] A backoff parameter value may indicate a maximum candidate backoff parameter value. There may be a pre-defined minimum, e.g., 0. The candidate backoff time values may be backoff time values that lie in the range 0 to the backoff parameter value. For instance, the candidate backoff time values may be all integer values (e.g., in ms) between the pre-defined minimum and the maximum candidate backoff parameter value.

[0108] The backoff indicator may influence the probability of further collisions for those transmissions that use a backoff time determined based on the backoff indicator. In the example given above, the higher the backoff indicator (e.g., the index to look-up) , the higher the backoff parameter value, and, thus, the larger the range of candidate backoff time values and, thus, the smaller the probability of a single candidate backoff time value being selected as backoff time for a transmission. In other words, the probability that different UEs determine different backoff times may increase with an increased number of candidate backoff time values.

[0109] The backoff parameter value may be used in determining the threshold with which the determined backoff time associated with the potential retransmission of the contention-based message is compared. In various embodiments, the threshold is a product of the backoff parameter value and the fallback ratio. For example, the backoff parameter value may be 60 ms (e.g., for a backoff indicator indicating a value of 5, see the example mapping provided above) and the fallback ratio may, e.g., be 1 / 3. The threshold may be determined as 60 ms *1 / 3 = 20 ms.

[0110] The backoff indicator may be comprised in the response. For example, there may be a number of bits and / or a field representing the backoff indicator. In some embodiments, the backoff indicator may be implicitly signaled in the response.

[0111] In various embodiments, the backoff indicator may be:

[0112] - comprised in a backoff indicator MAC subheader in the response (e.g., in the BI field of the backoff indicator MAC subheader) ;

[0113] - comprised in a system information block, SIB; or

[0114] - comprised in an RRC message.

[0115] In an embodiment, the backoff indicator may be obtained as a default value. For example, if no backoff indicator is received from the network, the UE may infer the backoff indicator to be a pre-defined default value. In some embodiments, it may be possible that the backoff indicator is obtained, but indicates a “Reserved” value (e.g., actually representing a fallback ratio) . For example in such cases, a backoff parameter value may be determined to be a pre-defined value.

[0116] As mentioned before, there are different options to attempt to mitigate the issue of further collisions between retransmitted contention-based messages and / or random access preambles of UEs after a collision has already occurred between contention-based messages of the UE.

[0117] In the following, a second option will be described. This second option can be applied jointly with the first option relating to the fallback ratio. Alternatively, the second option can be implemented independently (e.g., without) the first option. For example, in various embodiments, the response may comprise a fallback indication (e.g., fallback MAC CE) , instructing all UEs for which the contention resolution was not successful (and just not a fraction) to fallback to transmitting the random access preamble.

[0118] The UE may, if it is determined to fallback to transmitting the random access preamble, determine a backoff time for transmitting the random access preamble based on a probability distribution of candidate backoff time values; and transmit the random access preamble based on the determined backoff time.

[0119] The concept of determining a backoff time has been described before in the context of a backoff time associated with a potential retransmission of the contention-based message. The concept equally applies in the present context of determining a backoff time for transmitting the random access preamble. The backoff time may be the same or different in the different contexts. In various embodiments, the backoff time for transmitting the random access preamble and the backoff time associated with the potential retransmission of the contention-based message are the same.

[0120] In other embodiments, the backoff times are different. In such embodiments, the backoff times may be based on a common backoff indicator or based on different backoff indicators (whereas, if there is only one common backoff time, it can be assumed that there is only one common backoff indicator) .

[0121] For example, in various embodiments, the backoff indicator may be a common backoff indicator for determining the backoff time associated with the potential retransmission of the contention-based message and for determining the backoff time for transmitting the random access preamble.

[0122] In some embodiments, the UE may obtain a backoff indicator for determining the backoff time for transmitting the random access preamble. The backoff indicator may be different and / or independent from a backoff indicator associated with a potential retransmission of a contention-based message.

[0123] For example, it is determined by the UE to fallback to transmitting the random access preamble, the random access preamble is transmitted without delaying it by the determined backoff time associated with the potential retransmission of the contention-based message. Rather, the random access preamble may be transmitted based on delaying it by the determined backoff time for the random access preamble transmission.

[0124] It is possible that there is no backoff indicator associated with a potential retransmission of a contention-based message. There can still be a backoff indicator for determining the backoff time for transmitting the random access preamble.

[0125] In various embodiments, the backoff indicator for determining the backoff time for transmitting the random access preamble is:

[0126] (a) comprised in the response;

[0127] (b) comprised in a backoff indicator MAC subheader in the response;

[0128] (c) comprised in a system information block, SIB;

[0129] (d) comprised in a RRC message; or

[0130] (e) obtained as a default value.

[0131] The explanations given in this regard with respect to the backoff indicator associated with the potential retransmission of the contention-based message apply equally. Any combination of how the backoff indicator for determining the backoff time for transmitting the random access preamble and of how the backoff indicator associated with a potential retransmission of the contention-based message is conceivable. This may lead to a combination as follows (denoted in the format “backoff indicator associated with the potential retransmission of the contention-based message …; backoff indicator for determining the backoff time for transmitting the random access preamble …” ) :

[0132] - (a) comprised in the response; (a) comprised in the response;

[0133] - (a) comprised in the response; (b) comprised in a backoff indicator MAC subheader in the response;

[0134] - (a) comprised in the response; (c) comprised in a SIB

[0135] - (a) comprised in the response; (d) comprised in a RRC message;

[0136] - (a) comprised in the response; (e) obtained as a default value

[0137] - (b) comprised in a backoff indicator MAC subheader in the response ; (a) comprised in the response;

[0138] - (b) comprised in a backoff indicator MAC subheader in the response; (b) comprised in a backoff indicator MAC subheader in the response

[0139] - (b) comprised in a backoff indicator MAC subheader in the response; (c) comprised in a SIB;

[0140] - (b) comprised in a backoff indicator MAC subheader in the response; (d) comprised in a RRC message;

[0141] - (b) comprised in a backoff indicator MAC subheader in the response; (e) obtained as a default value

[0142] - (c) comprised in a SIB; (a) comprised in the response;

[0143] - (c) comprised in a SIB; (b) comprised in a backoff indicator MAC subheader in the response

[0144] - (c) comprised in a SIB; (c) comprised in a SIB ;

[0145] - (c) comprised in a SIB; (d) comprised in a RRC message;

[0146] - (c) comprised in a SIB; (e) obtained as a default value

[0147] - (d) comprised in a RRC message; (a) comprised in the response

[0148] - (d) comprised in a RRC message; (b) comprised in a backoff indicator MAC subheader in the response;

[0149] - (d) comprised in a RRC message; (c) comprised in a SIB;

[0150] - (d) comprised in a RRC message; (d) comprised in a RRC message;

[0151] - (d) comprised in a RRC message; (e) obtained as a default value;

[0152] - (e) obtained as a default value; (a) comprised in the response;

[0153] - (e) obtained as a default value; (b) comprised in a backoff indicator MAC subheader in the response;

[0154] - (e) obtained as a default value; (c) comprised in a SIB;

[0155] - (e) obtained as a default value; (d) comprised in a RRC message;

[0156] - (e) obtained as a default value; (e) obtained as a default value

[0157] Above, actions and / or configurations have been described from a point of view of a UE. It is to be understood that a network entity is equally disclosed that performs the counterpart for the UE.

[0158] According to an embodiment, a network entity may:

[0159] receive, from a plurality of UEs, a plurality of contention-based messages using an uplink channel; transmit a response indicative of an unsuccessful contention resolution for at least some UEs of the plurality of UEs;

[0160] and further perform at least one of (i) or (ii) :

[0161] (i) transmitting information relating to a fallback ratio to control a ratio of the at least some UEs that retransmit a contention-based message and to control a ratio of the at least some UEs that fallback to transmitting a random access preamble; or

[0162] (ii) transmitting a backoff indicator, the backoff indicator being associated with candidate backoff time values for allowing one or more of the at least some UEs to respectively determine, based on a probability distribution of the candidate backoff time values, a backoff time for transmitting a random access preamble.

[0163] Each of the options (i) and (ii) can, in an embodiment, standalone without the other option. There may be an embodiment where a network entity is configured for both options (i) and (ii) .

[0164] In option (i) , a fallback ratio is used. The fallback ratio may be indicative of a probability with which a UE of the at least some UEs is statistically expected to fallback to transmitting the random access preamble.

[0165] Regardless of whether option (ii) is implemented or not, the network entity may transmit a backoff indicator for allowing one or more of the at least some UEs to respectively determine based on a probability distribution of candidate backoff time values, a backoff time associated with a potential retransmission of the contention-based message. The respective backoff time associated with a potential retransmission of the contention-based message may be used by a UE to delay its retransmission of the contention-based message and / or may be used in the context of implementing the fallback ratio, e.g., for determining a backoff time that can be compared with a threshold.

[0166] It is to be understood that the presentation in this section is merely by way of examples and non-limiting. Each step described above may happen after or in response to another, e.g., the preceding step. However, a different order of steps is also possible.

[0167] Other features will become apparent from the following detailed description considered in conjunction with the accompanying drawings. It is to be understood, however, that the drawings are designed solely for purposes of illustration and not as a definition of the limits, for which reference should be made to the appended claims. It should be further understood that the drawings are not drawn to scale and that they are merely intended to conceptually illustrate the structures and procedures described herein.BRIEF DESCRIPTION OF THE DRAWINGS

[0168] The drawings are showing:

[0169] Fig. 1 an example system comprising a network entity and multiple UEs;

[0170] Fig. 2 a flowchart showing a method, e.g., performed by a UE, according to an example embodiment;

[0171] Fig. 3 a flowchart showing a method, e.g., performed by a network entity, according to an example embodiment;

[0172] Fig. 4 a flowchart showing a method, e.g., performed by a UE, according to an example embodiment;

[0173] Fig. 5 a flowchart showing a method, e.g., performed by a network entity, according to an example embodiment;

[0174] Fig. 6 an example message sequence according to an embodiment;

[0175] Fig. 7 an example message sequence according to an embodiment;

[0176] Fig. 8 a schematic block diagram of an apparatus according to an embodiment.

[0177] DETAILED DESCRIPTION OF SOME EXAMPLES

[0178] The following description serves to deepen the understanding and shall be understood to complement and be read together with the description as provided in the above summary section of this specification. Some aspects may have a different terminology than e.g. provided in the description above. The skilled person will nevertheless understand that those terms refer to the same subject-matter, e.g. by being more specific.

[0179] Fig. 1 shows an example system 100 comprising UEs 1-4 and a network entity 10 which, by way of example, is a base station.

[0180] A UE 1-4 may be any device used to access and / or communicate within a mobile communication network. Examples include smartphones, tablets, IoT devices, vehicles or other wireless-enabled endpoints. The UEs 1-4 may support various communication technologies such as LTE, 5G, 6G, and / or Wi-Fi enabling connectivity across different network environments. The UEs 1-4 may interact with one or more network entities for services including voice calls, data sessions, messaging, and / or multimedia applications. A UE 1-4 may comprise a radio transceiver module for transmitting and / or receiving signals over one or more access technologies, a baseband processing unit that may perform modulation, demodulation, encoding, decoding, and / or protocol stack processing, and / or a SIM or UICC that may store subscriber credentials and / or network configuration data. The UEs 1-4 may include application processors for executing software and / or user applications, power management components for regulating energy consumption, and / or antenna systems for signal propagation and / or reception. Additional elements may include memory modules, user interface components, and / or sensors, depending on device type and / or use case. Base station or network entity 10 or network node may serve as a node in mobile communication networks that facilitates wireless communications between UE and the core network. The base station may manage various radio resources to support uplink and / or downlink transmissions. The base station may handle tasks such as call setup, mobility management, and / or handover procedures. The base station may operate at different frequencies and / or bands to provide coverage in specific geographical areas. The base station may include components such as antennas, amplifiers, modems and / or control units that facilitate wireless communication.

[0181] While Fig. 1 shows a terrestrial network, it is to be understood that embodiments can be used in non-terrestrial networks (NTNs) , where they may be particularly useful because of the limited uplink capacity and the high latency.

[0182] Any (or each) of the UEs 1-4 may transmit a contention-based message, e.g., as part of a random access procedure. A purpose of a random access procedure may be to synchronize the UE 1-4 with the base station in terms of timing advance for subsequent data transmissions. Additional purposes include but are not limited to facilitating connection establishment, request for dedicated resources, or handover procedures between different cells. The successful completion of a random access procedure may allow the UE to transition from an idle state to an active state where it can initiate or / or receive data communications with other network entities.

[0183] To support capacity enhancements for uplink, it may be beneficial to reduce uplink and downlink signaling.

[0184] By way of example, this may be relevant in the context of a Early Data Transmission (EDT) .

[0185] To reduce necessary uplink and / or downlink signaling, the use of a contention-based message (in particular a contention-based (CB) -Msg3 transmission without msg1 / RAR) and / or an efficient delivery of Msg4 may be considered.

[0186] A resource for transmitting a contention-based message may be the same for a plurality of UEs 1-4. Configuration information from the network may be used to indicate the resource. For example, system information may be used to provide the resource (e.g., cell-specific CB-Msg3 PUSCH resources) . As a result, this is one of the scenarios where the configured resource is shared between UEs 1-4. Multiple UEs 1-4 may transmit the contention-based messages (e.g., CB-Msg3) on the same resource simultaneously, which may cause a collision. Due to the collision, the NW may not decode the messages successfully at all. Under various circumstances, the collision may bring adverse consequences such as the increased signalling overhead, additional UE power consumption or waste of the resource.

[0187] To address the collision issue, two approaches can be considered.

[0188] According to the first approach, a backoff mechanism can be introduced for the contention-based message retransmission. The principle may be adopted from the backoff mechanism supported in 4-step or 2-step random access procedure.

[0189] For the 4-step random access procedure, the NW may include a Backoff indicator (e.g., BI field) in a RAR message. The BI field may be 4-bits. The value may be configured to identify the overload condition in the cell. Each index of the value indicated by the BI field may represent a different backoff parameter value (e.g., a different time in unit ms) . For UEs which failed to complete the random access procedure (no matter after RAR reception or Msg4 reception) , the UE may select a random backoff time according to a uniform distribution between 0 and the Backoff Parameter Value. The UE may then delay the subsequent random-access preamble transmission by the backoff time.

[0190] Applying this principle to the contention-based messages, the UE may try a retransmission of the contention-based message (e.g., another CB-Msg3 transmission attempt) on a network configured resource (e.g., a network configured CB-Msg3 resource) after a backoff time. Further collisions may be mitigated by this approach as the UEs delay the subsequent transmission for another contention-based message re-attempt by a respective backoff time.

[0191] According to the second approach, a fallback mechanism for contention-based messages (e.g., CB-Msg3) may be introduced. For instance, instead of transmitting a re-attempt of the contention-based message on a network configured contention-based message resource, the UE may fallback to the transmission of a random access preamble, e.g., a 4-step RACH or 4-step RACH EDT, on a preamble resource. Further collisions may be mitigated as the UEs will access the system using preamble resource instead of the contention-based message resource.

[0192] Different directions can be considered for triggering the fallback from the contention-based message transmission (e.g., CB-Msg3 transmission) to transmission of a random access preamble (e.g., as part of 4-step RACH and / or EDT) .

[0193] According to a first direction, the UE may trigger the fallback. The UE may do so, for example, if the number of contention-based message transmission re-attempts reached a threshold. The threshold may be a maximum number of transmission attempts which may, for instance, be configured by NW or pre-defined.

[0194] For this first direction, it may be the UE behavior to decide the fallback. If multiple times of contention-based message transmission failed (e.g., due to collision on shared resource or bad RF conditions) , UE itself can fallback to random access preamble transmission (e.g., 4-step RACH) by selecting another resource (e.g., preamble resource) for system access.

[0195] According to a second direction, the NW may trigger the fallback. The network may do so by sending a NW fallback indication to UEs in a response to the contention-based message. The response may be a CB-Msg4. The fallback indication may, for instance, be a DL fallback MAC CE in the CB-Msg4.

[0196] For the second direction, it is NW behavior to control the load of the contention-based message resource. When the NW would like to offload UEs from re-attempting over the contention-based message resource (e.g., because the NW detects high load on the contention-based messages) , NW may issue a fallback indication in the response to the contention-based message (e.g., MAC CE in the CB-Msg4) to immediately order fallback to the UEs who receive the response to the contention-based message. To be precise, the fallback may be ordered for those UEs for which the contention resolution was not successful, e.g., a contention resolution identity in the response does not match an identity transmitted in the contention-based message. Under some circumstances, the NW-indicated fallback (second direction) may be a quicker mechanism than the threshold-based fallback (first direction) .

[0197] The first and / or second direction described above allow a reaction to colliding contention-based messages of UEs. However, it is possible to devise further measures that may improve the system.

[0198] As described before, multiple UEs may share the same contention-based message resource. Hence, all these UEs may monitor the same response (e.g., CB-Msg4) for contention resolution (e.g., with the same Msg4 C-RNTI) . It is possible that one response can accommodate multiple UEs for contention resolution simultaneously. However, it is still possible that for other UEs contention resolution cannot be accommodated.

[0199] Furthermore, if Diversity Slotted Aloha (DSA) is enabled by NW, multiple UEs may share the same resource within a contention-based message transmission window in which each UE may select K replica occasions within the window. For example, the transmission window may be configured by the network with a starting point (e.g. Hyper-System Frame Number (H-SFN) offset) , a window length, and a window periodicity (window length and periodicity could be the same) . The UE may first select the next DSA transmission window and then randomly select K replicas inside the window. Also in such a scenario, there may be multiple UEs that monitor the same response for contention resolution.

[0200] The resource for the contention-based messages may be the same for multiple UEs. For example, it may be cell-specific (and, e.g., not UE-specific) . For instance, the contention-based message (e.g., CB-Msg3) resource configuration and / or the contention-based message (e.g., CB-Msg3) transmission window (for instance for DSA) may be provided to UE via SIB. It may thus occur that the NW does not know how many UEs will use the contention-based message resource. Therefore, it is possible that NW is not aware how many UEs will monitor the corresponding response (e.g., CB-Msg4) simultaneously for contention resolution.

[0201] If NW issues a fallback indicator (e.g., MAC CE) in the response (e.g., in CB-Msg4) to instruct fallback to the UEs who receive the response to transmitting a random access preamble (e.g., fallback to 4-step RACH and / or EDT) , there may be a large number of UEs that may trigger fallback and then transmit the preamble in the next available preamble occasion. Consequently, it may cause a preamble collision (e.g., in the PRACH procedure) . That may especially be the case when the EDT and / or multiple Coverage Enhancement levels are supported as this will partition the preamble resource a lot. Such partitioning of the preamble resource may particularly occur in an IoT system.

[0202] In some scenarios, such kind of preamble collision may deteriorate the random-access rate and / or access latency, which preferably would be avoided.

[0203] Therefore, it is proposed to modify the fallback mechanism from contention-based message transmission (e.g., CB-Msg3 / Msg4 procedure) to transmission of a random access preamble (e.g., 4-step RACH / EDT) . In some scenarios, this may allow to mitigate the preamble collision in the preamble transmission. The proposed modifications may be applicable, for instance, for the case when NW detects the high load on contention-based message (e.g., CB-Msg3) resource and issues a fallback indication (e.g., in a response to the contention-based message, such as CB-Msg4) to offload UEs from re-attempting over the contention-based message resource to random access via preamble resource. Thus, embodiments may especially be used in the context of a NW-controlled fallback mechanism, for instance from CB-Msg3 to 4-step RACH and / or EDT.

[0204] In the following, a first option is explained with reference to Figs. 2 and 3. This first option may, in some embodiments, allow to control the ratio of UEs to fallback from contention-based message (re) transmissions (e.g., CB-Msg3 / CB-Msg4 procedure) to transmissions of random access preamble (e.g., as part of a 4-step RACH and / or EDT) .

[0205] Fig. 2 is a flowchart showing a method 200, e.g., performed by a UE, according to an example embodiment.

[0206] By way of example, the method 200 comprises: 201: transmitting a contention-based message using an uplink channel;

[0207] 202: receiving a response indicative of an unsuccessful contention resolution for the UE;

[0208] 203: determining whether to retransmit the contention-based message or to fallback to transmitting a random access preamble;

[0209] 204: based on the determining, retransmitting the contention-based message or transmitting the random access preamble.

[0210] By way of example, the method further comprises obtaining information relating to a fallback ratio (e.g., as part of step 202 or in a separate step, e.g., before step 202 or even before step 201) . The determining whether to retransmit the contention-based message or to fallback to transmitting a random access preamble in step 203 is then based on the fallback ratio.

[0211] Fig. 3 is a flowchart showing a method 300, e.g., performed by a network entity, according to an example embodiment.

[0212] By way of example, the method 300 comprises:

[0213] 301: receiving, from a plurality of UEs, a plurality of contention-based messages using an uplink channel; 302: transmitting a response indicative of an unsuccessful contention resolution for at least some UEs of the plurality of UEs.

[0214] By way of example, the method further comprises transmitting information relating to a fallback ratio (e.g., as part of step 302 or before step 302 or even before step 301) to control a ratio of the at least some UEs that retransmit a contention-based message and to control a ratio of the at least some UEs that fallback to transmitting a random access preamble.

[0215] Use of the fallback ratio may be implemented in variety of ways.

[0216] For example, the NW may include a backoff indicator (BI) (e.g., in a BI field) in the response. The NW may do so, for example, when the load on the contention-based messages resources is high. Based on the backoff indicator, the UE may select a random backoff time according to a probability distribution (for instance, a uniform distribution, a Gamma distribution or a multimodal distribution) between a pre-determined value (e.g., 0) and the Backoff Parameter Value (indicated by BI) . For example, UE could be configured to, based on the backoff parameter, select a random backoff time according to a uniform distribution between 0 and the Backoff Parameter Value; and delay a subsequent transmission by the backoff time. The UE may decide to fallback or not depending on the backoff time it derives from the backoff indicator (BI) field and the ratio of indicated fallback.

[0217] In an embodiment, the fallback ratio may be indicated via bits in the response. For example, the fallback ratio may be indicated by R (reserved) bits in a MAC subheader, for instance a MAC subheader for BI.

[0218] The MAC subheader for BI (or any other MAC subheader) may, for instance, have a format comprising or consisting of one or more of: 1 E bit, 1 T bit, 2 R bits, and 4 BI bits. These bits may have one or more of following properties (where it shall be understood that the role of 0 and 1 may be reversed) :

[0219] E: The Extension field may be a flag indicating if more fields are present in the MAC header or not. The E field may be set to "1" to indicate at least another set of E / T / RAPID fields follows. The E field may be set to "0" to indicate that a MAC RAR or padding starts at the next byte.

[0220] T: The Type field may be a flag indicating whether the MAC subheader contains a Random Access ID or a Backoff Indicator. The T field may be set to "0" to indicate the presence of a Backoff Indicator field in the subheader (BI) . The T field may be set to "1" to indicate the presence of a Random Access Preamble ID field in the subheader (RAPID) .

[0221] R: Reserved bit, may be used to indicate the fallback ratio and otherwise be set to 0.

[0222] BI: The Backoff Indicator field may identify the overload condition in a cell. The size of the BI field may be 4 bits.

[0223] The MAC header and subheaders may be octet aligned.

[0224] The mechanism to control the fallback ratio may be based on the random backoff time derived by UE.

[0225] For example, 2 R bits in the subheader of BI may be used to indicate a ratio (e.g., 1 / 4, 1 / 2 or 3 / 4, All) of the UEs to fallback (e.g., to 4-step RACH or EDT) . For instance, if 1 / 4 fallback is indicated, UEs whose derived random backoff value falls into the first (or last) 3 quarters (i.e. 1 / 4 or 1-1 / 4) may continue with contention-based message (e.g., CB-MSG3) re-attempt using the contention-based message (e.g., CB-Msg3) resource after its derived backoff value. UEs whose derived random backoff value fall into the last (or first) quarter of the distribution may fallback, e.g., to transmitting a random access preamble (for instance, as part of 4-step RACH and / or EDT) . In some scenarios, this may result in a lower load both for the preamble resource and the contention-based message resource.

[0226] In an embodiment, the fallback ratio may be indicated via SIB or RRC message. The mechanism to control the fallback ratio may be based on the random backoff time derived by UE, as explained before. For example, the ratio (e.g., none, 1 / 4, 1 / 2 or 3 / 4) can be cell-specific or UE-specific via SIB or RRC. The ratio may be given as part of a configuration for transmission of configuration-based messages, e.g., CB-Msg3 configuration. How the UE determines whether to fallback may be the same as previously described.

[0227] In another embodiment, the mechanism to control the fallback ratio may be based on the UE’s identity (e.g., IMSI) . The ratio can be indicated via SIB or RRC or the R bits in MAC subheader of BI or any other way described before. The UE may decide to fallback or not depending on the value of {UE_ID mod (denominator of the ratio) } and the ratio of indicated fallback. For example, if the fallback ratio is 1 / 4, then UE may calculate {UE_ID mod 4 } . If the calculated result / value is less than (or less than or equal to) the numerator of the ratio (e.g. 1 in this case) , then it may fallback to transmitting a random access preamble, e.g., as a first step of 4-step RACH and / or EDT. In another example, if the fallback ratio is 3 / 4, then UE may use {UE_ID mod 4 } as well. If the result / value is less than (or less than or equal to) the numerator of the ratio (e.g. 3 in this case) , then it may fallback, e.g., to 4-step RACH and / or EDT. UEs which decide not to fallback may continue with retransmissions of the contention-based messages in the contention-based message resource (e.g., MSG3 re-attempt using the CB-Msg3 resource) after the derived back off.

[0228] In an embodiment, the fallback ratio may be represented by a value in a backoff indicator field that is reserved for representing the fallback ratio. For instance, the reserved values of a BI table may be used to indicate the fallback ratio (e.g. as 1 / 4, 1 / 2, all) . The BI value may then be provided, e.g., in RRC or SIB or interpreted as the maximum value or default value of the table.

[0229] An example of a BI table is shown below. It is to be understood that the available indices and the specific backoff parameter values in the BI table are examples only so that the table may look different than the one shown below.

[0230] As can be seen, the BI table maps an index to a corresponding backoff parameter value. Such a BI table may be used for determining a backoff parameter value based on a backoff indicator. Once the backoff parameter value is found, a UE may select (e.g., randomly according to a probability distribution) a backoff time from a range of candidate backoff time values that are characterized by the determined backoff parameter value.

[0231] For example, a UE may receive a BI of 2. It may use the BI table to look-up the backoff parameter value for the index 2, i.e., 512 ms. Thus, the UE may, based on the backoff parameter as indicated by a BI field, select a random backoff time according to a uniform distribution between 0 and the backoff parameter value (e.g., 512) and delay the subsequent transmission by the backoff time.

[0232] It is to be understood that there may be multiple BI tables, e.g., depending on the circumstances and / or for different message types. For example, there can be one BI table for determining a backoff time associated with a retransmission of a contention-based message and another BI table for determining a backoff time for random access preamble transmission. In another example, there is a common BI table that is used by a UE for determining a backoff time associated with a potential retransmission of a contention-based message and for determining a backoff time for random access preamble transmission. Then the UE may, for instance, receive two BIs (e.g., one relating to a potential retransmission of a contention-based message and one relating to a backoff time for random access preamble transmission) and use the same BI table to derive two backoff parameter values and determine two backoff times (e.g., one relating to a potential retransmission of a contention-based message and one relating to a backoff time for random access preamble transmission) , for instance, each drawn from the range 0 to the respective backoff parameter value. Alternatively, the UE may receive a common BI, use the BI table to derive a common backoff parameter value and determine two backoff times based on the common backoff parameter value (e.g., one relating to a potential retransmission of a contention-based message and one relating to a backoff time for random access preamble transmission) , for instance, each drawn from the range 0 to the common backoff parameter value. In yet another example, the UE may receive a common BI, use the BI table to derive a common backoff parameter value and determine a common backoff time based on the common backoff parameter value (e.g., a common backoff time relating to both a potential retransmission of a contention-based message and to a random access preamble transmission) .

[0233] In one embodiment, the UEs who fallback to random access preamble transmission (e.g., as part of 4-step RACH and / or EDT) will not consider a determined backoff time when they trigger the preamble transmission. For instance, this may be because the determined backoff time may be associated with a potential retransmission of the contention-based message only and / or for respecting the fallback ratio only but does not concern a random access preamble transmission. There may or may not be a separate backoff time for random access preamble transmission.

[0234] By way of example, it can be seen that indices 13 to 15 of the BI table above are Reserved. These may be reserved for indicating a fallback ratio (e.g. as 1 / 4, 1 / 2, all) . For instance, if the UE receives a value in a BI field corresponding to index 14 of the BI table, it may conclude that the fallback ratio is 1 / 2.

[0235] Above, a first option to modify the fallback mechanism from contention-based message transmission to transmission of a random access preamble has been described with reference to Figs. 2 and 3. The first option involved using a fallback ratio.

[0236] In the following, a second option will be described with reference to Figs. 4 and 5. According to this second option, a backoff time for fallback, e.g., backoff from the response triggering the fallback to the preamble transmission, may be used.

[0237] Fig. 4 is a flowchart showing a method 400, e.g., performed by a UE, according to an example embodiment.

[0238] By way of example, the method 400 comprises:

[0239] 401: transmitting a contention-based message using an uplink channel;

[0240] 402: receiving a response indicative of an unsuccessful contention resolution for the UE;

[0241] 403: determining whether to retransmit the contention-based message or to fallback to transmitting a random access preamble;

[0242] 404: based on the determining, retransmitting the contention-based message or transmitting the random access preamble.

[0243] By way of example, the method 400 comprises, if it is determined to fallback to transmitting the random access preamble (step 403) , determining a backoff time for transmitting the random access preamble based on a probability distribution of candidate backoff time values (e.g., as part of step 403 or 404 or as a separate step) and transmitting the random access preamble based on the determined backoff time (step 404) .

[0244] Fig. 5 is a flowchart showing a method 500, e.g., performed by a network entity, according to an example embodiment.

[0245] By way of example, the method 500 comprises:

[0246] 501: receiving, from a plurality of UEs, a plurality of contention-based messages using an uplink channel;

[0247] 502: transmitting a response indicative of an unsuccessful contention resolution for at least some UEs of the plurality of UEs.

[0248] By way of example, the method 500 comprises transmitting a backoff indicator (e.g., as part of step 502 or in a separate step) , the backoff indicator being associated with candidate backoff time values for allowing one or more of the at least some UEs to respectively determine, based on a probability distribution of the candidate backoff time values, a backoff time for transmitting a random access preamble.

[0249] Use of the backoff time for transmitting the random access preamble may be implemented in variety of ways.

[0250] The backoff time for transmitting the random access preamble may be used, for instance, when NW indicates the fallback, e.g., using a fallback ratio, as described above, or indicates the fallback using a fallback instruction for all UEs whose contention resolution was not successful.

[0251] The backoff time may be determined by the UE based on a backoff indicator. Examples of determining a backoff time from a backoff indicator have been explained above, inter alia involving use of a look-up table (e.g., a BI table) . Any of these examples can be applied here.

[0252] The backoff indicator may be received by the UE from the network or otherwise obtained, e.g., as a default value from memory.

[0253] In one embodiment, a fallback indication and a BI for determining a backoff time for random access preamble transmission may be included in a same message from the NW to the UE, for example, in the response to the contention-based message. For instance, when the NW indicates the fallback (e.g., in a fallback MAC CE) in the response (e.g., CB-Msg4) , the Backoff indicator (BI field) could be included in the same CB-Msg4.

[0254] In another embodiment, the fallback indication can be indicated with one bit in the subheader for BI. It has been explained before how a fallback ratio (that may serve as fallback indication) can be signaled. In case the fallback indication does not relate to a fallback ratio but rather indicates whether all or none of the UEs has to fallback, this may be signaled, e.g., by a flag.

[0255] After receiving the fallback indication, e.g., in the response to the contention-based message, some or all of the the UEs receiving the response (except the one with matching contention resolution identity in the contention-based message, if any) may fallback from the contention-based message retransmission procedure (e.g., CB-Msg3 / Msg4 procedure) to transmitting a random access preamble (e.g., 4-step RACH and EDT) .

[0256] Based on the backoff parameter indicated by the BI, one or more of each of the UEs that fallback may select a random backoff time according to a probability distribution (e.g., a uniform distribution) between a pre-determined minimum value (e.g., 0) and the Backoff Parameter Value (indicated by BI) . Fallback indication with BI = 0 may mean a fallback (e.g., to 4-step RACH / EDT) without backoff.

[0257] The UEs may delay the subsequent preamble transmission (e.g., as part of 4-step RACH and EDT) by the derived backoff time.

[0258] In an embodiment, the NW may indicate the fallback MAC CE (or fallback indicator, e.g., in MAC subheader) in the response to the contention-based message (which may be a CB-Msg4) . The Backoff indicator (BI field) for fallback may be included in the SIB message or RRC message.

[0259] In an embodiment, the NW may indicate the fallback to transmitting a random access preamble (e.g., as part of 4-step RACH) via one of the reserved values in the backoff indicator table. The BI for the fallback may be included in SIB or RRC message.

[0260] Thus, a cross-message type (contention-based message to random access preamble) backoff time can be used. To that end, BI may be included in a response to a contention-based message, e.g., a CB-Msg4 or MsgB.

[0261] Above, a first option to modify the fallback mechanism from contention-based message transmission to transmission of a random access preamble has been described with reference to Figs. 2 and 3 and a second option has been described with reference to Figs. 4 and 5.

[0262] According to an embodiment, the combination of the first and the second option can be supported. This is illustrated with reference to Fig. 6.

[0263] Fig. 6 shows an example message sequence 600 between a UE 1 and a NW 10 according to an embodiment.

[0264] By way of example, the message sequence 600 comprises:

[0265] The UE 1 may transmit a contention-based message to the NW 10, e.g., using an uplink channel (601) . The NW may receive not only from UE 1, but from a plurality of UEs comprising UE 1, a plurality of contention-based messages, e.g., using an uplink channel. The contention-based message may be a CB-Msg3 or a MsgA. The uplink channel may be an uplink shared channel, e.g., UL-SCH or PUSCH.

[0266] The NW 10 may transmit a response indicative of an unsuccessful contention resolution for at least some UEs (by way of example, also for UE 1) of the plurality of UEs (602) . Thus, UE 1 receives a response indicative of an unsuccessful contention resolution for UE 1 (602) . The response may be, e.g., a CB-Msg4 or a MsgB.

[0267] NW 10 may transmit information relating to a fallback ratio (e.g., as part of step 602 or separately of step 602) to control a ratio of the at least some UEs that retransmit a contention-based message and to control a ratio of the at least some UEs that fallback to transmitting a random access preamble.

[0268] Moreover, NW 10 may transmit a backoff indicator (e.g., as part of step 602 or in a separate step) , the backoff indicator being associated with candidate backoff time values for allowing one or more of the at least some UEs to respectively determine, based on a probability distribution of the candidate backoff time values, a backoff time for transmitting a random access preamble.

[0269] UE 1 may determine whether to retransmit the contention-based message or to fallback to transmitting a random access preamble, e.g., based on the fallback ratio (603) . UE 1 may use an identifier associated with it and / or may use a derived backoff time as a basis for the determining.

[0270] If the UE 1 determines to fallback to transmitting the random access preamble in step 603, the UE may transmit the random access preamble (604a) . The UE may determine a backoff time for transmitting the random access preamble based on a probability distribution of candidate backoff time values (e.g., based on the backoff indicator transmitted by the NW 10) and it may transmit the random access preamble based on the determined backoff time. The transmission of random access preamble in step 604a may be a (e.g., first) step of another type of random access procedure, e.g., a 4-step RACH or 4-step EDT. The transmission of the random access preamble may be done using the physical random access channel, PRACH.

[0271] Alternatively, if UE 1 determines to retransmit the contention-based message, UE 1 may retransmit the contention-based message (604b) (e.g., in an uplink channel, as in the original transmission) . The UE 1 may or may not delay the contention-based message according to a backoff time, e.g., a backoff time used as a basis for the determining in step 603, a backoff time associated with a potential random access preamble transmission and / or a backoff time associated with a potential retransmission of the contention-based message.

[0272] For partial fallback, separate or common BI field could be applied for the UEs that fallback to random access preamble transmission (e.g., as part of 4-step RA) and the UEs that continue with contention-based message (re) transmission (e.g., CB-Msg3) . For example, for the common BI, the BI value can be provided via the MAC subheader. For example, in case of separate fields one or both BI values can be indicated in SIB or RRC or one of the two BI values can be in the BI of the subheader and the other in SIB / RRC. It is possible to use the BI field + a number (e.g., 2) of R bits of the MAC subheader divided so that 3 bits can be used for a first BI (e.g., CB-Msg3 BI) and 3 bits can be used for a second BI (e.g., the 4-step RA BI) .

[0273] To give a numerical example for the case of a common BI field, the response in step 602 may include a BI. By way of example, this BI could indicate a backoff parameter value of 10 ms (e.g., retrieved using a mapping in a lookup table) . Thus, there could be a range of candidate backoff time values from 0 to 10 ms. The fallback ratio could be indicated as 1 / 2, e.g., in the response in step 602. UE 1 could then in step 603 calculate a threshold as 1 / 2 *10 ms = 5 ms. Further, UE 1 could determine a backoff time from the candidate backoff time values according to a uniform probability distribution. The result could be a backoff time of 3 ms. UE 1 could compare this determined backoff time of 3 ms with the threshold of 5 ms and find that it is below the threshold. Based on that, UE 1 could determine that it has to fallback to the transmission of a random access preamble. Depending on the embodiment and / or the configuration of UE 1, UE 1 may then use the derived backoff time of 3 ms for delaying the transmission of the random access preamble in step 604a or determine another backoff value (e.g., according to the same procedure as before and / or based on the same BI) for the transmission of the random access preamble.

[0274] As explained above, separate BI fields may be possible so that the determining of the other backoff value in the example above may be done based on another BI.

[0275] Fig. 7 shows an example message sequence 700 between a UE 1 and a NW 10 according to an embodiment. The message sequence 700 may take place in a terrestrial network (TN) or a non-terrestrial network (NTN) .

[0276] By way of example, a specific embodiment is shown in Fig. 7 as follows:

[0277] 701: CB-Msg3 configuration, optionally including the fallback ratio parameter.

[0278] 702: CB-Msg3.

[0279] 703: Msg4 including backoff indicator, optionally including the fallback ratio parameter (e.g., when it was not included in CB-Msg3 configuration or otherwise transmitted to UE) .

[0280] 704: Calculate backoff time based on the backoff indicator.

[0281] 705: Determine whether to fallback based on the backoff time and the fallback ratio parameter.

[0282] 706: In case of fallback, determine the backoff time for the PRACH transmission of 4-step RA.

[0283] 707: PRACH (Msg1) transmission based on the backoff time.

[0284] In the following, and by way of example, a further embodiment is presented in a hierarchical form.

[0285] 1. UE receives contention-based message (e.g, msg3) configuration.

[0286] a. This can be via SIB, RRC, MAC CE or any other means

[0287] b. This can include fallback ratio (e.g., fallback ratio parameters / interpretation)

[0288] i. The fallback ratio can be cell specific or UE specific.

[0289] c. This can include fallback backoff timer configuration, e.g., a configuration for determining a backoff time.

[0290] 2. UE transmits the contention-based message (e.g., msg3 signaling) .

[0291] 3. UE receives response (e.g., msg4 transmission) , for instance with fallback indicator (e.g., in the form of a fallback ratio) and / or backoff indicator.

[0292] a. This can include fallback ratio (e.g., fallback ratio parameters / interpretation) .

[0293] i. The fallback ratio can be included in 2 reserved bits in MAC subheader for backoff indicator.

[0294] ii. The fallback ratio can be included in reserved values of backoff indicator table.

[0295] iii. The fallback ratio can be cell specific or UE specific.

[0296] b. This can include fallback backoff timer configuration, e.g., a configuration for determining a backoff time.

[0297] i. The fallback backoff timer can be included in reserved bits in MAC subheader for backoff indicator.

[0298] ii. The fallback backoff timer can be included in reserved values of backoff indicator table.

[0299] 4. UE determines whether to fallback or continue with contention-based message (e.g., msg3) retransmission based on the received information.

[0300] a. The determination of fallback can be based on received fallback ratio (e.g., fallback ratio parameters / interpretation) and received backoff indicator for random backoff time selection in response (e.g., in msg4) .

[0301] b. The determination of fallback can be based on received fallback ratio (e.g., fallback ratio parameters / interpretation) and UE identity.

[0302] c. The determination can be based on received fallback backoff timer.

[0303] 5. UE transmits the random access preamble (e.g., msg1) or retransmits the contention-based message (e.g., msg3) based on the determination regarding the fallback.

[0304] A further embodiment may be as follows. From network point of view, if the network detects high overload condition in the cell (e.g., the CB-Msg3 resource is in congestion) , the network may offload the UEs from re-attempting over the CB-Msg3 resource. The network may ask UEs to fallback to legacy 4-step RACH or EDT. In this case, the network can issue a fallback indicator in the CB-Msg4 to immediately order fallback to legacy RACH procedure. In this embodiment, the UEs who decode the CB-Msg4 but without matching contention resolution identity should fallback to legacy 4-step RACH and / or EDT procedure. If many UEs fall back to 4-step RACH or EDT procedures, the congestion issue may be shifted to the preamble domain. Similar to the backoff for preamble re-attempt, in this embodiment, the UEs performing fallback from CB-Msg3 to preamble transmission may apply a backoff time before transmitting the preamble. Thus, network-indicated fallback mechanism may be supported for CB-Msg3 EDT. In this embodiment, a UE with failed contention resolution shall fallback to legacy 4-step RACH and / or EDT procedure if it receives a fallback indicator in CB-Msg4. For example, the fallback indicator may comprise a fallback ratio.

[0305] It is to be understood that the fallback indicator and backoff indicator can be sent together or only one of them is sent. Without backoff parameters, the fallback UEs may trigger random access preamble transmission (e.g., Msg1 transmission) without delay. With backoff parameters, for the partial UEs which trigger the backoff, they may delay the random access preamble (e.g., Msg1) transmission by the time derived from the backoff parameters.

[0306] Fig. 8 shows a schematic block diagram of an example of an apparatus 800, e.g., a UE or a network entity or a part thereof, according to an embodiment.

[0307] Apparatus or network entity 800 comprises a processor 801, program memory 802, working or main memory 803, data memory, communication interface (s) 804, and an optional user interface 805.

[0308] Apparatus 800 may for instance be configured to perform and / or control or comprise respective means (at least one of 801 to 805) for performing and / or controlling the method according to any example aspect. Apparatus 800 may as well constitute a UE or network entity comprising at least one processor 801 and at least one memory 802 storing instructions that, when executed by the at least one processor, cause a (e.g., the) UE or network entity at least to perform and / or control the method according to any or all example aspects.

[0309] Processor 801 may for instance control at least one of the memories 802 to 803, the communication interface (s) 804, and / or the optional user interface 805.

[0310] Processor 801 may for instance execute program code stored in program memory 802, which may for instance represent a readable storage medium comprising program code that, when executed by processor 801, causes the processor 801 to perform the method according to any example aspect.

[0311] Processor 801 (and also any other processor mentioned in this specification) may be a processor of any suitable type. Processor 801 may comprise but is not limited to one or more microprocessor (s) , one or more processor (s) with accompanying one or more digital signal processor (s) , one or more processor (s) without accompanying digital signal processor (s) , one or more special-purpose computer chips, one or more field-programmable gate array (s) (FPGA (s) ) , one or more controller (s) , one or more application-specific integrated circuit (s) (ASIC (s) ) , or one or more computer (s)  / server (s) . The relevant structure / hardware has been programmed in such a way to carry out the described function. Processor 801 may for instance be an application processor that runs an operating system.

[0312] Program memory 802 may also be included into processor 801. This memory may for instance be fixedly connected to processor 801, or be at least partially removable from processor 801, for instance in the form of a memory card or stick. Program memory 802 may for instance be non-volatile memory. It may for instance be a FLASH memory (or a part thereof) , any of a ROM, PROM, EPROM and EEPROM memory (or a part thereof) or a hard disc (or a part thereof) , to name but a few examples. Program memory 802 may comprise an operating system for processor 801. Program memory 802 may comprise a firmware for apparatus or network entity 800.

[0313] Communication interface (s) 804 enable the apparatus 800 to communicate with other entities, e.g., one or more UE or one or more network nodes. The communication interface (s) 804 may for instance comprise a wireless interface, e.g., a cellular radio communication interface and / or a WLAN interface) and / or wire-bound interface, e.g., an IP-based interface, for instance to communicate with entities via the Internet. Communication interface (s) may enable apparatus 800 to communicate with other entities, for instance one or more entities as comprised in a mobile communication network.

[0314] User interface 805 is optional and may comprise a display for displaying information to a user and / or an input device (e.g. a keyboard, keypad, touchpad, mouse, etc. ) for receiving information from a user.

[0315] Some or all of the components of the apparatus 800 may for instance be connected via a bus. Some or all of the components of the apparatus or network entity 800 may for instance be combined into one or more modules.

[0316] An apparatus 800 may further comprise at least one of the following: a receiver, e.g., for receiving information, e.g., from a network entity or a UE, and a transmitter, e.g., for transmitting information, e.g., to a network entity or UE.

[0317] In the present specification, any presented connection in the described embodiments is to be understood in a way that the involved components are operationally coupled. Thus, the connections can be direct or indirect with any number or combination of intervening elements, and there may be merely a functional relationship between the components.

[0318] Moreover, any of the methods, processes and actions described or illustrated herein may be implemented using executable instructions in a general-purpose or special-purpose processor and stored on a computer-readable storage medium (e.g., disk, memory, or the like) to be executed by such a processor. References to a ‘computer-readable storage medium’ should be understood to encompass specialized circuits such as FPGAs, ASICs, signal processing devices, and other devices.

[0319] The expression “A and / or B” is considered to comprise any one of the following three scenarios: (i) A, (ii) B, (iii) A and B. Furthermore, the article “a” is not to be understood as “one” , i.e., use of the expression “an element” does not preclude that also further elements are present. The term “comprising” is to be understood in an open sense, i.e., in a way that an object that “comprises an element A” may also comprise further elements in addition to element A. Further, the term “comprising” may be understood to also disclose “consisting of” , i.e., consisting of only the specified elements.

[0320] The expression “at least one of the following: <a list of two or more elements>” and “at least one of <a list of two or more elements>” and similar wording, where the list of two or more elements are joined by “and” or “or” , mean at least any one of the elements, or at least any two or more of the elements, or at least all the elements.

[0321] It will be understood that all presented embodiments are only examples, and that any feature presented for a particular example embodiment may be used with any aspect on its own or in combination with any feature presented for the same or another particular example embodiment and / or in combination with any other feature not mentioned. In particular, the example embodiments presented in this specification shall also be understood to be disclosed in all possible combinations with each other, as far as it is technically reasonable and the example embodiments are not alternatives with respect to each other. It will further be understood that any feature presented for an example embodiment in a particular category (method / apparatus / computer program / system) may also be used in a corresponding manner in an example embodiment of any other category. It should also be understood that presence of a feature in the presented example embodiments shall not necessarily mean that this feature forms an essential feature and cannot be omitted or substituted.

[0322] The statement of a feature comprises at least one of the subsequently enumerated features is not mandatory in the way that the feature comprises all subsequently enumerated features, or at least one feature of the plurality of the subsequently enumerated features. Also, a selection of the enumerated features in any combination or a selection of only one of the enumerated features is possible. The specific combination of all subsequently enumerated features may as well be considered. Also, a plurality of only one of the enumerated features may be possible.

[0323] The sequence of all method steps presented above is not mandatory, also alternative sequences may be possible. Nevertheless, the specific sequence of method steps exemplarily shown in the drawings shall be considered as one possible sequence of method steps for the respective embodiment described by the respective drawing.

[0324] The subject-matter has been described above by means of example embodiments. It should be noted that there are alternative ways and variations which are obvious to a skilled person in the art and can be implemented without deviating from the scope of the appended claims.

[0325] Further numbered example embodiments are described below:

[0326] Example 1:

[0327] A method performed by a user equipment, UE, the method comprising:

[0328] transmitting a contention-based message to a network entity;

[0329] receiving a response indicative of an unsuccessful contention resolution for the UE;

[0330] determining whether to retransmit the contention-based message or to fallback to transmitting a random access preamble;

[0331] based on the determining, retransmitting the contention-based message or transmitting the random access preamble;

[0332] wherein the method further comprises at least one of (i) or (ii) :

[0333] (i) obtaining information relating to a fallback ratio; and

[0334] wherein the determining whether to retransmit the contention-based message or to fallback to transmitting a random access preamble is based on the fallback ratio; or

[0335] (ii) if it is determined to fallback to transmitting the random access preamble, determining a backoff time for transmitting the random access preamble based on a probability distribution of candidate backoff time values; and

[0336] transmitting the random access preamble based on the determined backoff time.

[0337] Example 2:

[0338] The method of Example 1, wherein the information relating to the fallback ratio is one of:

[0339] (a) represented by reserved bits in a backoff indicator medium access control, MAC, subheader in the response;

[0340] (b) represented by a value in a backoff indicator field that is reserved for representing the fallback ratio;

[0341] (c) comprised in a MAC control element, CE, in the response;

[0342] (d) comprised in a system information block, SIB; or

[0343] (e) comprised in a RRC message.

[0344] Example 3:

[0345] The method of Example 1 or 2, further comprising:

[0346] receiving configuration information relating to the transmitting of the contention-based message;

[0347] wherein the information relating to the fallback ratio is comprised in the configuration information.

[0348] Example 4:

[0349] The method any one of the preceding Examples, wherein the fallback ratio is indicative of a probability with which the UE is statistically expected to fallback to transmitting the random access preamble.

[0350] Example 5:

[0351] The method any one of the preceding Examples, wherein the determining whether to retransmit the contention-based message or to fallback to transmitting the random access preamble based on the fallback ratio is further based on an identifier associated with the UE.

[0352] Example 6:

[0353] The method of Example 5, wherein the determining whether to retransmit the contention-based message or to fallback to transmitting the random access preamble based on the fallback ratio and based on the identifier associated with the UE comprises:

[0354] applying, based on the fallback ratio, a modulo operation to the identifier associated with the UE;

[0355] deciding, based on a result of the modulo operation and the fallback ratio, whether to retransmit the contention-based message or to fallback to transmitting the random access preamble.

[0356] Example 7:

[0357] The method of any one of the preceding Examples, wherein the method further comprises determining, based on a probability distribution of candidate backoff time values, a backoff time associated with a potential retransmission of the contention-based message.

[0358] Example 8:

[0359] The method of Example 7, wherein the determining whether to retransmit the contention-based message or to fallback to transmitting the random access preamble based on the fallback ratio comprises:

[0360] determining, based on the fallback ratio and the probability distribution of candidate backoff time values, a threshold;

[0361] comparing the determined backoff time associated with the potential retransmission of the contention-based message with the threshold; and

[0362] deciding whether to retransmit the contention-based message or to fallback to transmitting the random access preamble based on an outcome of the comparing of the determined backoff time associated with the potential retransmission of the contention-based message with the threshold.

[0363] Example 9:

[0364] The method of Example 7 or 8, wherein, if it is determined to retransmit the contention-based message, the contention-based message is retransmitted based on the determined backoff time associated with the potential retransmission of the contention-based message.

[0365] Example 10:

[0366] The method of any one of Examples 7 to 9, wherein the method further comprises obtaining a backoff indicator for determining the backoff time associated with the potential retransmission of the contention-based message.

[0367] Example 11:

[0368] The method of Example 10, wherein the backoff indicator is associated with the candidate backoff time values for determining the backoff time associated with the potential retransmission of the contention-based message by specifying an index to a look-up table, wherein the look-up table maps the index to a backoff parameter value, and wherein the candidate backoff time values are backoff time values that lie in a range between a pre-defined minimum backoff time value and the backoff parameter value.

[0369] Example 12:

[0370] The method of Example 11, wherein the threshold is a product of the backoff parameter value and the fallback ratio.

[0371] Example 13:

[0372] The method of any one of Examples 10 to 12, wherein the backoff indicator is:

[0373] (a) comprised in the response;

[0374] (b) comprised in a backoff indicator MAC subheader in the response;

[0375] (c) comprised in a system information block, SIB;

[0376] (d) comprised in a RRC message; or

[0377] (e) obtained as a default value.

[0378] Example 14:

[0379] The method of any one of Examples 7 to 13, wherein, if it is determined to fallback to transmitting the random access preamble, the random access preamble is transmitted without delaying it by the determined backoff time associated with the potential retransmission of the contention-based message.

[0380] Example 15:

[0381] The method of any one of Examples 10 to 13, wherein the backoff indicator is a common backoff indicator for determining the backoff time associated with the potential retransmission of the contention-based message and for determining the backoff time for transmitting the random access preamble.

[0382] Example 16:

[0383] The method of Example 15, wherein the backoff time for transmitting the random access preamble and the backoff time associated with the potential retransmission of the contention-based message are the same.

[0384] Example 17:

[0385] The method of any one of Examples 1 to 14, further comprising obtaining a backoff indicator for determining the backoff time for transmitting the random access preamble.

[0386] Example 18:

[0387] The method of Example 17, wherein the backoff indicator for determining the backoff time for transmitting the random access preamble is:

[0388] (a) comprised in the response;

[0389] (b) comprised in a backoff indicator MAC subheader in the response;

[0390] (c) comprised in a system information block, SIB;

[0391] (d) comprised in a RRC message; or

[0392] (e) obtained as a default value.

[0393] Example 19:

[0394] The method of any one of the preceding Examples, wherein the contention-based message is a contention-based msg3 or a contention-based msgA.

[0395] Example 20:

[0396] The method of any one of the preceding Examples, wherein an uplink channel used for transmitting the contention-based message is an uplink shared channel.

[0397] Example 21:

[0398] The method of any one of the preceding Examples, wherein the random access preamble is transmitted using a random access channel, RACH.

[0399] Example 22:

[0400] The method of any one of the preceding Examples, wherein the transmission of the random access preamble is part of a 4-step random access procedure.

[0401] Example 23:

[0402] The method of any one of the preceding Examples, wherein the response comprises a fallback indication.

[0403] Example 24:

[0404] An apparatus, e.g., a UE, comprising means for performing the method of any one of the preceding Examples.

[0405] Example 25:

[0406] An apparatus comprising at least one processor; and at least one memory storing instructions that, when executed by the at least one processor, cause the apparatus at least to perform the method of any one of the preceding Examples.

[0407] Example 26:

[0408] A computer program, the computer program when executed by a processor causing one or more apparatuses, for instance a UE, to perform and / or control the actions of the method according to any one of the preceding Examples.

[0409] Example 27:

[0410] [Rectified under Rule 91, 10.04.2025]A computer readable storage medium (e.g. tangible and / or non-transitory) , the computer readable storage medium comprising at least the computer program of Example 26.

[0411] List of abbreviations:5G            5th Generation6G              6th GenerationASIC            Application-specific integrated circuitBI              Backoff IndicatorC-RNTI          Cell Radio-Network Temporary IdentifierCB-Msg3       Contention-based Msg3CCCH           Common Control ChannelCE              Control ElementDL              DownlinkDSA            Diversity Slotted AlohaDU             Distributed UnitEDT            Early Data TransmissionEEPROM       Electrically erasable PROMeNodeB         evolved NodeBEPROM         Erasable PROMFPGA           Field Programmable Gate ArrayH-SFN           Hyper-System Frame NumberIMSI            International Mobile Subscriber IdentityIoT             Internet of ThingsLTE             Long Term EvolutionMAC            Medium Access ControlMIB             Master Information BlockNB             NarrowbandNR             New RadioNTN            Non-Terrestrial NetworkNW             NetworkPDU            Protocol Data UnitPRACH          Physical RACHPUSCH          Physical Uplink Shared ChannelPROM           Programmable read-only memoryQoS             Quality of ServiceRACH           Random Access ChannelRAN            Radio Access NetworkRAPID          Random Access Preamble IDRAR            Random Access ResponseROM            Read-only memoryRRC            Radio Resource ControlSDU            Service Data UnitSIB             System information BlockSIM             Subscriber Identity ModuleTMSI            Temporary Mobile Subscriber IdentityTN             Terrestrial NetworkTRP            Transmission and Reception PointTV              TelevisionUE              User equipmentUICC            Universal Integrated Circuit CardUL-SCH         Uplink Shared ChannelWLAN          Wireless Local Area Network

Claims

1.A user equipment, UE, comprising:at least one processor; andat least one memory storing instructions that, when executed by the at least one processor, cause the UE at least to perform:transmitting a contention-based message to a network entity;receiving a response indicative of an unsuccessful contention resolution for the UE;determining whether to retransmit the contention-based message or to fallback to transmitting a random access preamble;based on the determining, retransmitting the contention-based message or transmitting the random access preamble;wherein the instructions, when executed by the at least one processor, further cause the UE to perform at least one of (i) or (ii) :(i) obtaining information relating to a fallback ratio; andwherein the determining whether to retransmit the contention-based message or to fallback to transmitting a random access preamble is based on the fallback ratio; or(ii) if it is determined to fallback to transmitting the random access preamble, determining a backoff time for transmitting the random access preamble based on a probability distribution of candidate backoff time values; andtransmitting the random access preamble based on the determined backoff time.2.The UE of claim 1, wherein the information relating to the fallback ratio is one of:(a) represented by reserved bits in a backoff indicator medium access control, MAC, subheader in the response;(b) represented by a value in a backoff indicator field that is reserved for representing the fallback ratio;(c) comprised in a MAC control element, CE, in the response;(d) comprised in a system information block, SIB; or(e) comprised in a RRC message.3.The UE of claim 1 or 2, wherein the instructions, when executed by the at least one processor, further cause the UE to perform:receiving configuration information relating to the transmitting of the contention-based message;wherein the information relating to the fallback ratio is comprised in the configuration information.4.The UE of any one of the preceding claims, wherein the fallback ratio is indicative of a probability with which the UE is statistically expected to fallback to transmitting the random access preamble.5.The UE of any one of the preceding claims, wherein the determining whether to retransmit the contention-based message or to fallback to transmitting the random access preamble based on the fallback ratio is further based on an identifier associated with the UE.6.The UE of claim 5, wherein the determining whether to retransmit the contention-based message or to fallback to transmitting the random access preamble based on the fallback ratio and based on the identifier associated with the UE comprises:applying, based on the fallback ratio, a modulo operation to the identifier associated with the UE;deciding, based on a result of the modulo operation and the fallback ratio, whether to retransmit the contention-based message or to fallback to transmitting the random access preamble.7.The UE of any one of the preceding claims, wherein the instructions, when executed by the at least one processor, further cause the UE to determine, based on a probability distribution of candidate backoff time values, a backoff time associated with a potential retransmission of the contention-based message.8.The UE of claim 7, wherein the determining whether to retransmit the contention-based message or to fallback to transmitting the random access preamble based on the fallback ratio comprises:determining, based on the fallback ratio and the probability distribution of candidate backoff time values, a threshold;comparing the determined backoff time associated with the potential retransmission of the contention-based message with the threshold; anddeciding whether to retransmit the contention-based message or to fallback to transmitting the random access preamble based on an outcome of the comparing of the determined backoff time associated with the potential retransmission of the contention-based message with the threshold.9.The UE of claim 7 or 8, wherein, if it is determined to retransmit the contention-based message, the contention-based message is retransmitted based on the determined backoff time associated with the potential retransmission of the contention-based message.10.The UE of any one of claims 7 to 9, wherein the instructions, when executed by the at least one processor, further cause the UE to obtain a backoff indicator for determining the backoff time associated with the potential retransmission of the contention-based message.11.The UE of claim 10, wherein the backoff indicator is associated with the candidate backoff time values for determining the backoff time associated with the potential retransmission of the contention-based message by specifying an index to a look-up table, wherein the look-up table maps the index to a backoff parameter value, and wherein the candidate backoff time values are backoff time values that lie in a range between a pre-defined minimum backoff time value and the backoff parameter value.12.The UE of claim 11, wherein the threshold is a product of the backoff parameter value and the fallback ratio.13.The UE of any one of claims 10 to 12, wherein the backoff indicator is:(a) comprised in the response;(b) comprised in a backoff indicator MAC subheader in the response;(c) comprised in a system information block, SIB;(d) comprised in a RRC message; or(e) obtained as a default value.14.The UE of any one of claims 7 to 13, wherein, if it is determined to fallback to transmitting the random access preamble, the random access preamble is transmitted without delaying it by the determined backoff time associated with the potential retransmission of the contention-based message.15.The UE of any one of claims 10 to 13, wherein the backoff indicator is a common backoff indicator for determining the backoff time associated with the potential retransmission of the contention-based message and for determining the backoff time for transmitting the random access preamble.16.The UE of claim 15, wherein the backoff time for transmitting the random access preamble and the backoff time associated with the potential retransmission of the contention-based message are the same.17.The UE of any one of claims 1 to 14, wherein the instructions, when executed by the at least one processor, further cause the UE to obtain a backoff indicator for determining the backoff time for transmitting the random access preamble.18.The UE of claim 17, wherein the backoff indicator for determining the backoff time for transmitting the random access preamble is:(a) comprised in the response;(b) comprised in a backoff indicator MAC subheader in the response;(c) comprised in a system information block, SIB;(d) comprised in a RRC message; or(e) obtained as a default value.19.The UE of any one of the preceding claims, wherein the contention-based message is a contention-based msg3 or a contention-based msgA.20.The UE of any one of the preceding claims, wherein an uplink channel used for transmitting the contention-based message is an uplink shared channel.21.The UE of any one of the preceding claims, wherein the random access preamble is transmitted using a random access channel, RACH.22.The UE of any one of the preceding claims, wherein the transmission of the random access preamble is part of a 4-step random access procedure.23.The UE of any one of the preceding claims, wherein the response comprises a fallback indication.24.A network entity comprising:at least one processor; andat least one memory storing instructions that, when executed by the at least one processor, cause the network entity at least to perform:receiving, from a plurality of UEs, a plurality of contention-based messages;transmitting a response indicative of an unsuccessful contention resolution for at least some UEs of the plurality of UEs;wherein the instructions, when executed by the at least one processor, further cause the network entity to perform at least one of (i) or (ii) :(i) transmitting information relating to a fallback ratio to control a ratio of the at least some UEs that retransmit a contention-based message and to control a ratio of the at least some UEs that fallback to transmitting a random access preamble; or(ii) transmitting a backoff indicator, the backoff indicator being associated with candidate backoff time values for allowing one or more of the at least some UEs to respectively determine, based on a probability distribution of the candidate backoff time values, a backoff time for transmitting a random access preamble.25.The network entity of claim 24, wherein the fallback ratio is indicative of a probability with which a UE of the at least some UEs is statistically expected to fallback to transmitting the random access preamble.26.The network entity of claim 24 or 25, wherein the information relating to the fallback ratio is one of:(a) represented by reserved bits in a backoff indicator MAC subheader in the response;(b) represented by a value in a backoff indicator field that is reserved for representing the fallback ratio;(c) comprised in a MAC CE in the response;(d) comprised in a system information block, SIB; or(e) comprised in a RRC message.27.The network entity of any one of claims 24 to 26, wherein the backoff indicator is:(a) comprised in the response;(b) comprised in a backoff indicator MAC subheader in the response;(c) comprised in a system information block, SIB; or(d) comprised in a RRC message.28.The network entity of any one of claims 24 to 27, wherein the instructions, when executed by the at least one processor, further cause the network entity to transmit a backoff indicator for allowing one or more of the at least some UEs to respectively determine, based on a probability distribution of candidate backoff time values, a backoff time associated with a potential retransmission of the contention-based message.29.A method performed by a user equipment, UE, the method comprising:transmitting a contention-based message to a network entity;receiving a response indicative of an unsuccessful contention resolution for the UE;determining whether to retransmit the contention-based message or to fallback to transmitting a random access preamble;based on the determining, retransmitting the contention-based message or transmitting the random access preamble;wherein the method further comprises at least one of (i) or (ii) :(i) obtaining information relating to a fallback ratio; andwherein the determining whether to retransmit the contention-based message or to fallback to transmitting a random access preamble is based on the fallback ratio; or(ii) if it is determined to fallback to transmitting the random access preamble, determining a backoff time for transmitting the random access preamble based on a probability distribution of candidate backoff time values; andtransmitting the random access preamble based on the determined backoff time.30.A method performed by a network entity, the method comprising:receiving, from a plurality of UEs, a plurality of contention-based messages;transmitting a response indicative of an unsuccessful contention resolution for at least some UEs of the plurality of UEs;wherein the method further comprises at least one of (i) or (ii) :(i) transmitting information relating to a fallback ratio to control a ratio of the at least some UEs that retransmit a contention-based message and to control a ratio of the at least some UEs that fallback to transmitting a random access preamble; or(ii) transmitting a backoff indicator, the backoff indicator being associated with candidate backoff time values for allowing one or more of the at least some UEs to respectively determine, based on a probability distribution of the candidate backoff time values, a backoff time for transmitting a random access preamble.

Images