Patent Description:
Random access in a wireless communication network may be performed by a wireless device to, for example, acquire uplink synchronization and/or to establish or resume a radio resource control (RRC) connection. The traditional contention-based random access procedure includes <NUM> steps in which the wireless device and network engage in two successive rounds of a wireless device transmission and a network response. To reduce the duration of the procedure and corresponding latency attributable to the procedure, a <NUM>-step random access procedure condenses the procedure into only one round of a wireless device transmission and a network response.

Some contexts complicate the <NUM>-step random access procedure. If the single network response in the <NUM>-step procedure includes all of the same information as the two network responses in the <NUM>-step procedure (e.g., including the RRC signalling), the delay and latency improvements from the <NUM>-step nature of the procedure are hampered. On the other hand, including only some of that information in the single network response of the <NUM>-step procedure, such that the remaining information (e.g., the RRC signalling) must be transmitted separately from the network response, may likewise hamper latency improvements in unlicensed frequency deployments that require the unlicensed frequency channel to be cleared before each separate transmission.

<NPL> discloses a solution for transmitting DL MAC SDU for SRB/DRB in <NUM>-step RACH.

<CIT> discloses a solution for transmitting a MAC PDU, containing an RRC message and a data volume and power headroom (DV-PH) report but no BSR, using a uplink grant received in a random access response.

<NPL>, is a collection of thoughts from different companies on the topic of procedures and msgB content.

A method performed by a wireless device, a method performed by a network node, a wireless device and a network node are provided as set out in the independent claims.

<FIG> shows a wireless communication network <NUM> according to some embodiments. The wireless communication network <NUM> includes a radio access network (RAN) 10A (e.g., based on New Radio, NR) and a core network (CN) 10B. The RAN 10A includes a network node <NUM> (e.g., base station) that provides radio access to a wireless device <NUM>. In some embodiments (e.g., where the RAN 10A is an NR Unlicensed, NR-U, network), this radio access may be provided in unlicensed frequency spectrum. The unlicensed frequency spectrum is frequency spectrum within which transmissions may be performed without a license from a licensor (which may be a regulatory or governing entity, e.g., the United States Federal Communications Commission, FCC, or the International Telecommunication Union, ITU). Regardless, the RAN 10A via the radio access connects the wireless device <NUM> to the CN 10B, which may in turn connect to one or more data networks (e.g., the Internet).

The wireless device <NUM> is configured to perform a random access procedure with the network node <NUM>. The random access procedure may for instance be performed in order for the wireless device <NUM> to acquire uplink synchronization, to establish or resume a radio resource control (RRC) connection, etc..

The random access procedure as shown includes two steps, e.g., as opposed to the conventional <NUM> steps. In the first step, the wireless device <NUM> performs a transmission <NUM> on a random access channel (RACH) and an uplink shared channel (e.g., a physical uplink shared channel, PUSCH). This transmission <NUM> may be referred to as MSG A. The transmission <NUM> on the RACH may convey a random access preamble. The transmission <NUM> on the uplink shared channel may convey an RRC establishment request or RRC resume request. The transmission <NUM> on the RACH and the transmission <NUM> on the uplink shared channel may be performed in the same subframe, or in successive subframes, e.g., such that the transmission <NUM> on the uplink shared channel is performed before any response is received to the transmission <NUM> on the RACH.

In the second step, the network node <NUM> transmits a response to the RACH and uplink shared channel transmission <NUM>. If the network node <NUM> successfully decoded the RACH and the uplink shared channel payload, the network node <NUM> transmits a random access success response message (also referred to as a random access success response, or simply, success response). This random access success response message correspondingly indicates that both the RACH and the uplink shared channel payload were decoded successfully. Note in this regard that, unlike the traditional <NUM>-step procedure, the random access success response is transmitted as a response to both the RACH and the uplink shared channel transmission <NUM>.

In any event, the network node <NUM> in some embodiments conveys this random access success response message <NUM> within or as a transmission referred to as MSG B. In one or more embodiments, for instance, the random access success response message <NUM> is included in a medium access control (MAC) protocol data unit (PDU) <NUM>. In one embodiment, this MAC PDU <NUM> may be a shared message that it is addressed to multiple wireless devices, e.g., because it includes multiple random access success responses for respective ones of the wireless devices. Regardless, in some embodiments, the random access success response message <NUM> includes a contention resolution identity, a cell radio network temporary identity (C-RNTI), a timing advance (TA) command, an uplink grant, and/or a random access preamble identifier (RAPID).

According to embodiments herein, it is configurable as to whether or not the MAC PDU <NUM> carrying the random access success response message <NUM> also includes a MAC service data unit (SDU) <NUM> for a signaling radio bearer (SRB) or a data radio bearer (DRB). The MAC SDU <NUM> for an SRB may convey for instance RRC signaling, e.g., in the form of one or more RRC messages such as an RRC setup message or an RRC resume message. Alternatively or additionally, the MAC SDU <NUM> for a DRB may convey user plane data, e.g., for an early data transmission. With regard to RRC signaling, then, it is configurable as to whether or not the MAC PDU <NUM> carrying the random access success response message <NUM> includes RRC signaling.

In some embodiments, this configurability is realized by way of the network node <NUM> transmitting information <NUM> to the wireless device <NUM>. The information <NUM> may for instance comprise system information (SI), e.g., included in a System Information Block Type <NUM>, SIB1, wherein the SIB1 indicates scheduling of one or more other System Information Blocks. In other embodiments, the information <NUM> may comprise or be included in dedicated RRC signaling. Regardless, in some embodiments, the information <NUM> (e.g., in the form of a flag <NUM>) indicates whether or not the MAC SDU <NUM> for an SRB or DRB is to be received by the wireless device <NUM> in the same MAC PDU as the MAC PDU <NUM> carrying the random access success response message <NUM>. Equivalently, the information <NUM> may indicate whether or not the MAC SDU <NUM> for an SRB or DRB is to be received by the wireless device <NUM> in a different MAC PDU than the MAC PDU <NUM> carrying the random access success response message <NUM>.

In some embodiments, the information <NUM> further indicates one or more parameter values that govern reception of the random access success response message <NUM> (or the MAC PDU <NUM> carrying the message <NUM>). For example, the one or more parameter values may include a value for a reception window within which the wireless device <NUM> must receive the random access success response message <NUM> or the MAC PDU <NUM> carrying the random access success response message <NUM>. Alternatively or additionally, the one or more parameter values may include an identity (e.g., Cell Radio Network Temporary Identity, C-RNTI, or Random Access RNTI, RA-RNTI) with which the wireless device <NUM> is to descramble a control channel on which, or a control channel search space within which, the random access success response message <NUM> or a MAC PDU <NUM> carrying the random access success response message <NUM> is to be sent. Alternatively or additionally, the information <NUM> may indicate a backoff procedure for random access by the wireless device <NUM>.

Regardless, in some embodiments, the wireless device <NUM> processes the received MAC PDU <NUM> based on the received information <NUM>. For example, in some embodiments, one or more parameter values governing random access depend on or are otherwise based on whether a MAC SDU <NUM> for an SRB or DRB is included in the received MAC PDU <NUM>. For example, in these and other embodiments, a random access response reception timer (corresponding to the reception window) has a value that depends or is based on whether the MAC SDU <NUM> for an SRB or DRB is to be received by the wireless device <NUM> in the same PAC PDU as a MAC PDU <NUM> carrying the random access success response message <NUM>. The timer value (and reception window) may be relatively larger or smaller, for instance, depending respectively on whether or not the MAC SDU <NUM> for the SRB or DRB is to be received by the wireless device <NUM> in the same PAC PDU as a MAC PDU <NUM> carrying the random access success response message <NUM>. In these and other embodiments, then, the wireless device <NUM> may determine the value for the random access response reception timer (i.e., the reception window) based on the received information <NUM>. Alternatively or additionally, a radio network temporary identity (e.g., C-RNTI) may be determined based on the received information <NUM>.

Configurability via the information <NUM> may advantageously enable the network node <NUM> to adapt inclusion of the MAC SDU <NUM> for SRB or DRB in the MAC PDU <NUM> carrying the success response <NUM>, e.g., on an as-needed basis to account for varying circumstances or conditions, or to account for a specific network deployment (e.g., in unlicensed frequency spectrum). In some embodiments, for instance, the network node <NUM> may determine whether or not the MAC SDU <NUM> for an SRB or DRB is to be included in the same MAC PDU as the MAC PDU <NUM> carrying the random access success response message <NUM> based on one or more of: a type of network deployment within which the network node <NUM> is deployed; expected radio resource control, RRC, processing delay; delay between a central unit and a distributed unit of the network node <NUM>; cell layout; a category or type of the wireless device <NUM>; whether the wireless device <NUM> is in connected mode, idle mode, or inactive mode; a random access trigger; a priority of the wireless device <NUM> or of a transmission for the wireless device <NUM>; a random access load; and/or radio resource control, RRC, processing load.

In view of the above modifications and variations, <FIG> depicts a method performed by a wireless device <NUM> in accordance with particular embodiments. The method includes receiving, from a network node <NUM>, information <NUM> indicating whether or not a medium access control, MAC, service data unit, SDU, <NUM> for a signaling radio bearer, SRB, or data radio bearer, DRB, is to be received by the wireless device <NUM> in the same MAC protocol data unit, PDU, as a MAC PDU <NUM> carrying a random access success response message <NUM> (Block <NUM>). In some embodiments, the random access success response message <NUM> indicates both a random access channel and an uplink shared channel payload were decoded successfully.

In some embodiments, the method may further include transmitting the random access channel and the uplink shared channel payload, e.g., as conveyed by msgA described herein (Block <NUM>). The method may alternatively or additionally include receiving a MAC PDU <NUM> carrying the random access success response message <NUM> (Block <NUM>). The method in some embodiments further includes processing the received MAC PDU <NUM> based on the received information <NUM> indicating whether a MAC SDU <NUM> for an SRB or DRB is included in the received MAC PDU <NUM> (Block <NUM>).

<FIG> depicts a method performed by a network node <NUM> in accordance with other particular embodiments. The method includes transmitting, from the network node <NUM> to a wireless device <NUM>, information <NUM> indicating whether or not a medium access control, MAC, service data unit, SDU, <NUM> for a signaling radio bearer, SRB, or data radio bearer, DRB, is to be received by the wireless device <NUM> in the same MAC protocol data unit, PDU, as a MAC PDU <NUM> carrying a random access success response message <NUM> (Block <NUM>). In some embodiments, the random access success response message <NUM> indicates both a random access channel and an uplink shared channel payload were decoded successfully.

In some embodiments, the method may further include receiving the random access channel and the uplink shared channel payload, e.g., as conveyed by msgA described herein (Block <NUM>). The method may alternatively or additionally include transmitting a MAC PDU <NUM> carrying the random access success response message <NUM> (Block <NUM>).

Note that the apparatuses described above may perform the methods herein and any other processing by implementing any functional means, modules, units, or circuitry. In one embodiment, for example, the apparatuses comprise respective circuits or circuitry configured to perform the steps shown in the method figures. The circuits or circuitry in this regard may comprise circuits dedicated to performing certain functional processing and/or one or more microprocessors in conjunction with memory. For instance, the circuitry may include one or more microprocessor or microcontrollers, as well as other digital hardware, which may include digital signal processors (DSPs), special-purpose digital logic, and the like. The processing circuitry may be configured to execute program code stored in memory, which may include one or several types of memory such as read-only memory (ROM), random-access memory, cache memory, flash memory devices, optical storage devices, etc. Program code stored in memory may include program instructions for executing one or more telecommunications and/or data communications protocols as well as instructions for carrying out one or more of the techniques described herein, in several embodiments. In embodiments that employ memory, the memory stores program code that, when executed by the one or more processors, carries out the techniques described herein.

<FIG> for example illustrates a wireless device <NUM> (e.g., wireless device <NUM>) as implemented in accordance with one or more embodiments. As shown, the wireless device <NUM> includes processing circuitry <NUM> and communication circuitry <NUM>. The communication circuitry <NUM> (e.g., radio circuitry) is configured to transmit and/or receive information to and/or from one or more other nodes, e.g., via any communication technology. Such communication may occur via one or more antennas that are either internal or external to the wireless device <NUM>. The processing circuitry <NUM> is configured to perform processing described above, e.g., in <FIG>, such as by executing instructions stored in memory <NUM>. The processing circuitry <NUM> in this regard may implement certain functional means, units, or modules.

<FIG> illustrates a network node <NUM> (e.g., network node <NUM>) as implemented in accordance with one or more embodiments. As shown, the network node <NUM> includes processing circuitry <NUM> and communication circuitry <NUM>. The communication circuitry <NUM> is configured to transmit and/or receive information to and/or from one or more other nodes, e.g., via any communication technology. The processing circuitry <NUM> is configured to perform processing described above, e.g., in <FIG>, such as by executing instructions stored in memory <NUM>. The processing circuitry <NUM> in this regard may implement certain functional means, units, or modules.

A computer program comprises instructions which, when executed on at least one processor of an apparatus, cause the apparatus to carry out any of the respective processing described above. A computer program in this regard may comprise one or more code modules corresponding to the means or units described above.

Additional embodiments will now be described. At least some of these embodiments may be described as applicable in certain contexts and/or wireless network types for illustrative purposes, but the embodiments are similarly applicable in other contexts and/or wireless network types not explicitly described. In the below embodiments, though, the wireless device <NUM> may be exemplified as a UE, the network node <NUM> may be exemplified as an eNB or gNB, the MAC SDU <NUM> for an SRB or DRB may be exemplified as conveying an RRC message, and the random access success response message <NUM> may be exemplified as a successRAR message. Accordingly, in the below embodiments, Option <NUM> corresponds to the MAC PDU <NUM> not including a MAC SDU <NUM> for an SRB or DRB, whereas Option <NUM> corresponds to the MAC PDU <NUM> including a MAC SDU <NUM> for an SRB or DRB.

<FIG> shows a legacy <NUM>-step Random Access (RA) that is the baseline for both Long Term Evolution (LTE) and New Radio (NR). The user equipment (UE) in this <NUM>-step procedure randomly selects a preamble to transmit. The UE then starts the ra-ResponseWindow in which the RA Response (RAR) message must be received. The maximum duration of the the ra-ResponseWindow is <NUM> (<NUM> is discussed for NR Unlicensed, NR-U).

When the eNB detects the preamble, it estimates the Timing alignment (TA) the UE should use in order to obtain uplink (UL) synchronization at the eNB. The eNB responds with the TA and a grant for Msg3 in the RAR message.

In Msg3, the UE transmits its identifier for contention resolution (part of RRC message or C-RNTI). Upon transmission of Msg3, the UE starts the ra-Contention Resolution Timer in which Msg4 must be received. The maximum configurable duration is <NUM> sub frames (<NUM>). The reason why this timer is longer than the ra-ResponseWindow is that it may involve RRC processing and needs to account for centralized unit (CU) / distributed unit (DU) delays, where a CU and DU may be different parts of the eNB that implement different layers of a protocol stack, e.g., the CU may terminate higher layer and/or less time-critical protocols, such as the Packet Data Convergence Protocol (PDCP) and Radio Resource Control (RRC) protocols, whereas the DU by contrast may terminate lower layer and/or more time-critical protocols, such as the Radio Link Control (RLC), Medium Access Control (MAC), and physical layer protocols.

In any event, te gNB responds by acknowledging the UE id in Msg <NUM>. The Msg <NUM> gives contention resolution, i.e. only one UE's identifier will be sent even if several UEs have used the same preamble (and Msg <NUM>) simultaneously. A UE which has successful contention resolution has successfully completed its random access procedure.

<FIG> shows an example of a MAC PDU consisting of MAC random access responses (RARs). A Medium Access Control (MAC) Protocol Data Unit (PDU) for RA Response (RAR or msg2) consists of one or more MAC subPDUs and optionally padding. Each MAC subPDU consists one of the following:.

A MAC subheader with Backoff Indicator consists of five header fields E/T/R/R/BI as described in <FIG> (corresponding to <FIG>. <NUM>-<NUM> of 3GPP TS <NUM> v15. A MAC subPDU with Backoff Indicator (BI) only is placed at the beginning of the MAC PDU, if included. 'MAC subPDU(s) with RAPID only' and 'MAC subPDU(s) with RAPID and MAC RAR' can be placed anywhere between MAC subPDU with Backoff Indicator only (if any) and padding (if any).

A MAC subheader with RAPID consists of three header fields E/T/RAPID as described in <FIG> (corresponding to <FIG>. <NUM>-<NUM> of TS <NUM> v15.

Padding is placed at the end of the MAC PDU if present. Presence and length of padding is implicit based on transport block (TB) size, size of MAC subPDU(s).

For both subheaders, the fields have the following explanations:.

If a UE receives a RAR with the E/T/R/R/BI mac subheader but no 'MAC subPDU(s) with RAPID and MAC RAR' with RAPID matching its preamble transmission, the UE will back-off for a random time between <NUM> and a time indicated by the BI field before doing a new preamble transmission attempt, i.e. return to Random Access Resource selection (Section <NUM>. <NUM> in <NUM> v15.

A <NUM>-step RA procedure gives much shorter latency than the ordinary <NUM> step RA. In the <NUM> step RA, the preamble (transmitted on PRACH) and a message corresponding to Message <NUM> (transmitted on PUSCH) in the <NUM> step RA are transmitted in the same or in two subsequent sub frames. The first message in the <NUM>-step procedure is denoted Message A (MsgA). The <NUM>-step procedure is depicted in <FIG>. In the <NUM>-step procedure, the grant is linked to a particular preamble. The same kind of mapping will be needed in the <NUM>-step procedure. For all different preamble ids that have been configured for the <NUM>-step there must be a mapping to a particular PUSCH resource. The PUSCH resource may be time multiplexed, frequency multiplexed or code multiplexed.

Upon successful reception of MsgA (i.e. both the preamble and Msg <NUM>), the eNB will respond with a TA (which by assumption should not be needed or just give very minor updates) and a Msg <NUM> for contention resolution. The second message in the <NUM>-step procedure is denoted Message B (MsgB) in NR-U.

In the two step procedure, there will be a timer, hereafter called "msgB reception timer", in which msgB must be received. It should be noted that in the <NUM>-step procedure, there were two different timers governing when the network response must be received. In the <NUM>-step procedure, only one is used.

In case the UE does not receive a MsgB, it would re-try with a new MsgA, similar to the action taken by the UE which does not receive a RAR in the <NUM>-step procedure.

In case the UE is in connected mode, MsgA may contain the UEs C-RNTI and the msgB may be identified by Physical Downlink Control Channel (PDCCH) scrambled by the C-RNTI and a TA and possibly an uplink (UL) grant.

In case the UE is in idle or inactive mode, msgA may contain common control channel (CCCH) (RRC message) and the msgB may include a contention resolution MAC Control Element (CE), TA, C-RNTI and most possibly an RRC message.

One option (referred to as Option <NUM>) is to have a "SuccessRAR" containing contention resolution MAC CE, TA, C-RNTI and possibly a RAPID. The SuccessRaAR is addressed to a single UE (not multiplexed), possibly using the RA-RNTI. After receiving the SuccessRAR, the contention resolution is complete and the gNB can send the RRC message part in a later stage. The advantage with this approach is that contention resolution can be carried out quickly, e.g. using a msgB reception timer with a setting corresponding to the ra-ResponseWindow in the <NUM>-step procedure. This is illustrated in <FIG>. In case the RRC message is to be included, this may mean extra latency to account for RRC processing and CU/DU delays implying the need for a longer setting of msgB reception timer (corresponding to the ra-ContentionResolutionTimer in the <NUM>-step procedure).

Another option (referred to as Option <NUM>) would be to not send a SuccessRAR and instead wait until a complete msgB can be sent. This has the advantage that only <NUM> LBTs (Listen Before Talk) are needed in case of NR-U (NR Unlicensed), compared to three LBTs if the RRC part is sent in a later stage. The overall latency would be similar (since the UE needs to wait until it receives the RRC part in case of the first option) between the options, except in case the SuccessRAR would fail LBT, in which case the second option would be better. This option is illustrated in <FIG>.

There currently exist certain challenge(s). As explained above, the setting of msgB reception timer depends on which of the two options (msgB sent in two steps or in one step) is used. Both options have advantages and may be preferable in different situations. However they may be difficult to use simultaneously. For example, the second option could require a longer length of msgB reception window compared to the first option using SuccessRAR. The two options could also require different RNTIs to identify msgB (e.g. first option might use RA-RNTI but the second option would need a new RNTI capable of handling longer reception windows). Furthermore, the methods to do back off could be different under the different options, since if a back off is sent in the shorter window, it might back off a user which otherwise would receive its msgB after the shorter window has expired.

Certain aspects of the present disclosure and their embodiments may provide solutions to these or other challenges. Some embodiments include a mechanism for how to configure the UE to know which of the options is used, e.g., by configuration.

Certain embodiments may provide one or more of the following technical advantage(s). Some embodiments enable a network to order the UE to follow a procedure consisting of a SuccessRAR and a later RRC message or a procedure where only one msgB containing both content from the SuccessRAR and the RRC message is included.

More particularly, consider now additional details of various embodiments for UEs which have transmitted a msgA in the <NUM>-step RA procedure. Option <NUM> is referred to as the case where msgB in the <NUM>-step Random Access procedure is sent in two steps: (i) A first step for contention resolution, C-RNTI assignment, and possibly TA command; and (ii) a second step consisting of an RRC message, e.g., as shown in <FIG>. Option <NUM> is referred to as the case where msgB in the <NUM>-step Random Access procedure is sent in one step (message/MAC PDU), e.g., as shown in <FIG>. The msgB in this option <NUM> may contain contention resolution, C-RNTI assignment, possibly TA command and RRC message.

As a first embodiment, the network configures in system information (SI) which option (Option <NUM> or Option <NUM>) is used. The configuration can be included in either the RACH-ConfigCommon or RACH-ConfigGeneric Information Element (IE) in System Information (SI) Block Type <NUM> (SIB1). The SI in some embodiments may contain a flag to indicate which option is configured and to indicate parameter values of the msgB reception window. The UE will then, based on the configuration in the SI, know which procedure to follow and which parameter values to use.

The procedures to follow for the different options may differ in terms of msgB reception window length, how to identify msgB (RNTI used for scrambling of PDCCH or PDCCH search space) and/or back off procedure.

The configuration of Option <NUM> or Option <NUM> may also consist of a mix of the two options, where option <NUM> is used for UEs in connected mode and option <NUM> is used for UEs in idle or inactive mode.

As a second embodiment, the option to use (Option <NUM> or Option <NUM>) is signaled through dedicated RRC signaling. An RRC message in this case may contain a flag to indicate which option is configured and to indicate parameter values of msgB reception window. The UE will then, based on the configuration in the RRC message, know which procedure to follow and which parameter values to use. This may be used in e.g. hand over.

The network may decide on which option to use based on network deployment including expected RRC delays, CU/DU fronthaul or backhaul delay and/or cell layout.

Alternatively or additionally, the network may decide on which option to use based on UE categories and/or random access trigger. For example, UEs doing random access for high priority use cases may use one option while other UEs use the other option. This could be specified in the 3GPP standard and possibly combined with configuration in SI.

Alternatively or additionally, the selected option may be based on load, e.g. random access load, RRC processing load.

Although the subject matter described herein may be implemented in any appropriate type of system using any suitable components, the embodiments disclosed herein are described in relation to a wireless network, such as the example wireless network illustrated in <FIG>. For simplicity, the wireless network of <FIG> only depicts network <NUM>, network nodes <NUM> and 1360b, and WDs <NUM>, 1310b, and 1310c. In practice, a wireless network may further include any additional elements suitable to support communication between wireless devices or between a wireless device and another communication device, such as a landline telephone, a service provider, or any other network node or end device. Of the illustrated components, network node <NUM> and wireless device (WD) <NUM> are depicted with additional detail. The wireless network may provide communication and other types of services to one or more wireless devices to facilitate the wireless devices' access to and/or use of the services provided by, or via, the wireless network.

Thus, particular embodiments of the wireless network may implement communication standards, such as Global System for Mobile Communications (GSM), Universal Mobile Telecommunications System (UMTS), Long Term Evolution (LTE), Narrowband Internet of Things (NB-IoT), and/or other suitable <NUM>, <NUM>, <NUM>, or <NUM> standards; wireless local area network (WLAN) standards, such as the IEEE <NUM> standards; and/or any other appropriate wireless communication standard, such as the Worldwide Interoperability for Microwave Access (WiMax), Bluetooth, Z-Wave and/or ZigBee standards.

As used herein, wireless device (WD) refers to a device capable, configured, arranged and/or operable to communicate wirelessly with network nodes and/or other wireless devices. Unless otherwise noted, the term WD may be used interchangeably herein with user equipment (UE). Communicating wirelessly may involve transmitting and/or receiving wireless signals using electromagnetic waves, radio waves, infrared waves, and/or other types of signals suitable for conveying information through air. In some embodiments, a WD may be configured to transmit and/or receive information without direct human interaction. For instance, a WD may be designed to transmit information to a network on a predetermined schedule, when triggered by an internal or external event, or in response to requests from the network. Examples of a WD include, but are not limited to, a smart phone, a mobile phone, a cell phone, a voice over IP (VoIP) phone, a wireless local loop phone, a desktop computer, a personal digital assistant (PDA), a wireless cameras, a gaming console or device, a music storage device, a playback appliance, a wearable terminal device, a wireless endpoint, a mobile station, a tablet, a laptop, a laptop-embedded equipment (LEE), a laptop-mounted equipment (LME), a smart device, a wireless customer-premise equipment (CPE). a vehicle-mounted wireless terminal device, etc.. A WD may support device-to-device (D2D) communication, for example by implementing a 3GPP standard for sidelink communication, vehicle-to-vehicle (V2V), vehicle-to-infrastructure (V2I), vehicle-to-everything (V2X) and may in this case be referred to as a D2D communication device. As yet another specific example, in an Internet of Things (IoT) scenario, a WD may represent a machine or other device that performs monitoring and/or measurements, and transmits the results of such monitoring and/or measurements to another WD and/or a network node. The WD may in this case be a machine-to-machine (M2M) device, which may in a 3GPP context be referred to as an MTC device. As one particular example, the WD may be a UE implementing the 3GPP narrow band internet of things (NB-loT) standard. Particular examples of such machines or devices are sensors, metering devices such as power meters, industrial machinery, or home or personal appliances (e.g. refrigerators, televisions, etc.) personal wearables (e.g., watches, fitness trackers, etc.). In other scenarios, a WD may represent a vehicle or other equipment that is capable of monitoring and/or reporting on its operational status or other functions associated with its operation. A WD as described above may represent the endpoint of a wireless connection, in which case the device may be referred to as a wireless terminal. Furthermore, a WD as described above may be mobile, in which case it may also be referred to as a mobile device or a mobile terminal.

WD <NUM> may include multiple sets of one or more of the illustrated components for different wireless technologies supported by WD <NUM>, such as, for example, GSM, WCDMA, LTE, NR, WiFi, WiMAX, NB-IoT, or Bluetooth wireless technologies, just to mention a few.

In certain embodiments, some or all of the functionality described herein as being performed by a WD may be provided by processing circuitry <NUM> executing instructions stored on device readable medium <NUM>, which in certain embodiments may be a computerreadable storage medium.

UE <NUM> may be any UE identified by the <NUM>rd Generation Partnership Project (3GPP), including a NB-loT UE, a machine type communication (MTC) UE, and/or an enhanced MTC (eMTC) UE.

Network connection interface <NUM> may be configured to provide a communication interface to network 1443a. Network 1443a may encompass wired and/or wireless networks such as a local-area network (LAN), a wide-area network (WAN), a computer network, a wireless network, a telecommunications network, another like network or any combination thereof. For example, network 1443a may comprise a Wi-Fi network.

In <FIG>, processing circuitry <NUM> may be configured to communicate with network 1443b using communication subsystem <NUM>. Network 1443a and network 1443b may be the same network or networks or different network or networks. Communication subsystem <NUM> may be configured to include one or more transceivers used to communicate with network 1443b.

Network 1443b may encompass wired and/or wireless networks such as a local-area network (LAN), a wide-area network (WAN), a computer network, a wireless network, a telecommunications network, another like network or any combination thereof. For example, network 1443b may be a cellular network, a Wi-Fi network, and/or a near-field network.

<FIG> illustrates a telecommunication network connected via an intermediate network to a host computer in accordance with some embodiments. In particular, with reference to <FIG>, in accordance with an embodiment, a communication system includes telecommunication network <NUM>, such as a 3GPP-type cellular network, which comprises access network <NUM>, such as a radio access network, and core network <NUM>. Access network <NUM> comprises a plurality of base stations 1612a, 1612b, 1612c, such as NBs, eNBs, gNBs or other types of wireless access points, each defining a corresponding coverage area 1613a, 1613b, 1613c. Each base station 1612a, 1612b, 1612c is connectable to core network <NUM> over a wired or wireless connection <NUM>. A first UE <NUM> located in coverage area 1613c is configured to wirelessly connect to, or be paged by, the corresponding base station 1612c. A second UE <NUM> in coverage area 1613a is wirelessly connectable to the corresponding base station 1612a.

Telecommunication network <NUM> is itself connected to host computer <NUM>, which may be embodied in the hardware and/or software of a standalone server, a cloudimplemented server, a distributed server or as processing resources in a server farm.

Example implementations, in accordance with an embodiment, of the UE, base station and host computer discussed in the preceding paragraphs will now be described with reference to <FIG> illustrates host computer communicating via a base station with a user equipment over a partially wireless connection in accordance with some embodiments In communication system <NUM>, host computer <NUM> comprises hardware <NUM> including communication interface <NUM> configured to set up and maintain a wired or wireless connection with an interface of a different communication device of communication system <NUM>.

It is noted that host computer <NUM>, base station <NUM> and UE <NUM> illustrated in <FIG> may be similar or identical to host computer <NUM>, one of base stations 1612a, 1612b, 1612c and one of UEs <NUM>, <NUM> of <FIG>, respectively.

Wireless connection <NUM> between UE <NUM> and base station <NUM> is in accordance with the teachings of the embodiments described throughout this disclosure. One or more of the various embodiments improve the performance of OTT services provided to UE <NUM> using OTT connection <NUM>, in which wireless connection <NUM> forms the last segment.

Other objectives, features and advantages of the enclosed embodiments will be apparent from the description.

Claim 1:
A method performed by a wireless device (<NUM>), the method comprising:
receiving (<NUM>), from a network node (<NUM>), information indicating whether or not a medium access control, MAC, service data unit, SDU, for a signaling radio bearer, SRB, or data radio bearer, DRB, is to be received by the wireless device in the same MAC protocol data unit, PDU, as a MAC PDU carrying a random access success response message, wherein the random access success response message indicates both a random access channel and an uplink shared channel payload were decoded successfully.