Patent Description:
Wireless communication technologies are moving the world towards a rapidly increasing network connectivity. High-speed and low-latency wireless communications rely on efficient network resource management and allocation between user mobile stations and wireless access network nodes (including but not limited to wireless base stations). Unlike traditional circuit-switched networks, efficient wireless access networks may not rely on dedicated user channels. Instead, wireless network resources (such as carrier frequencies and transmission time slots) for transmitting voice or other types of data from mobile stations to wireless access network nodes may be allocated on a contention-based random access basis rather than a grant-based fixed access basis.

3GPP Draft R2-<NUM>, 3GPP Draft R2-<NUM> and 3GPP Draft R2-<NUM> are related prior art documents.

Any embodiments, aspects, examples or implementations not claimed, are only presented as information.

In various telecommunications systems a contention-based random access channel may be used. In contention-based systems multiple-possible transmitters, e.g., in a mobile telecommunications context, user equipment (UE), may send a request message to a basestation, which may be a nodeB (NB, e.g., an eNB or gNB) in a mobile telecommunications context. The basestation may respond to the UE request messages by providing a grant to transmit for one of the requestors and an indication of a network congestion (e.g., a backoff indicator) for other ones on the requestors. In some cases, where the requests themselves are transmitted on the random access channel, the UEs may have a backoff/retransmit system for handling incidental and interfering simultaneous requests to transmit.

<FIG> shows an example basestation <NUM>. The example basestation may include radio Tx/Rx circuitry <NUM> to receive and transmit with UEs <NUM>. The basestation may also include network interface circuitry <NUM> to couple the basestation to the core network <NUM>, e.g., optical or wireline interconnects, Ethernet, and/or other data transmission mediums/protocols.

The basestation may also include system circuitry <NUM>. System circuitry <NUM> may include processor(s) <NUM> and/or memory <NUM>. Memory <NUM> may include operations <NUM> and control parameters <NUM>. Operations <NUM> may include instructions for execution on one or more of the processors <NUM> to support the functioning the basestation. For example, the operations may handle random access transmission requests from multiple UEs. The control parameters <NUM> may include parameters or support execution of the operations <NUM>. For example, control parameters may include network protocol settings, random access messaging format rules, bandwidth parameters, radio frequency mapping assignments, and/or other parameters.

<FIG> shows an example random access messaging environment <NUM>. In the random access messaging environment a UE <NUM> may communicate with a basestation <NUM> over a random access channel <NUM>. In this example, the UE <NUM> supports one or more Subscriber Identity Modules (SIMs), such as the SIM1 <NUM>. Electrical and physical interface <NUM> connects SIM1 <NUM> to the rest of the user equipment hardware, for example, through the system bus <NUM>.

The mobile device <NUM> includes communication interfaces <NUM>, system logic <NUM>, and a user interface <NUM>. The system logic <NUM> may include any combination of hardware, software, firmware, or other logic. The system logic <NUM> may be implemented, for example, with one or more systems on a chip (SoC), application specific integrated circuits (ASIC), discrete analog and digital circuits, and other circuitry. The system logic <NUM> is part of the implementation of any desired functionality in the UE <NUM>. In that regard, the system logic <NUM> may include logic that facilitates, as examples, decoding and playing music and video, e.g., MP3, MP4, MPEG, AVI, FLAC, AC3, or WAV decoding and playback; running applications; accepting user inputs; saving and retrieving application data; establishing, maintaining, and terminating cellular phone calls or data connections for, as one example, Internet connectivity; establishing, maintaining, and terminating wireless network connections, Bluetooth connections, or other connections; and displaying relevant information on the user interface <NUM>. The user interface <NUM> and the inputs <NUM> may include a graphical user interface, touch sensitive display, haptic feedback or other haptic output, voice or facial recognition inputs, buttons, switches, speakers and other user interface elements. Additional examples of the inputs <NUM> include microphones, video and still image cameras, temperature sensors, vibration sensors, rotation and orientation sensors, headset and microphone input / output jacks, Universal Serial Bus (USB) connectors, memory card slots, radiation sensors (e.g., IR sensors), and other types of inputs.

The system logic <NUM> may include one or more processors <NUM> and memories <NUM>. The memory <NUM> stores, for example, control instructions <NUM> that the processor <NUM> executes to carry out desired functionality for the UE <NUM>. The control parameters <NUM> provide and specify configuration and operating options for the control instructions <NUM>. The memory <NUM> may also store any BT, WiFi, <NUM>, <NUM>, <NUM> or other data <NUM> that the UE <NUM> will send, or has received, through the communication interfaces <NUM>.

In various implementations, the system power may be supplied by a power storage device, such as a battery <NUM>
In the communication interfaces <NUM>, Radio Frequency (RF) transmit (Tx) and receive (Rx) circuitry <NUM> handles transmission and reception of signals through one or more antennas <NUM>. The communication interface <NUM> may include one or more transceivers. The transceivers may be wireless transceivers that include modulation / demodulation circuitry, digital to analog converters (DACs), shaping tables, analog to digital converters (ADCs), filters, waveform shapers, filters, pre-amplifiers, power amplifiers and/or other logic for transmitting and receiving through one or more antennas, or (for some devices) through a physical (e.g., wireline) medium.

The transmitted and received signals may adhere to any of a diverse array of formats, protocols, modulations (e.g., QPSK, <NUM>-QAM, <NUM>-QAM, or <NUM>-QAM), frequency channels, bit rates, and encodings. As one specific example, the communication interfaces <NUM> may include transceivers that support transmission and reception under the <NUM>, <NUM>, BT, WiFi, Universal Mobile Telecommunications System (UMTS), High Speed Packet Access (HSPA)+, and <NUM> / Long Term Evolution (LTE) standards. The techniques described below, however, are applicable to other wireless communications technologies whether arising from the 3rd Generation Partnership Project (3GPP), GSM Association, 3GPP2, IEEE, or other partnerships or standards bodies.

Referring now to <FIG> shows example multiple step random access protocols <NUM>, <NUM>. In various implementations, a UE and basestation may engage in a multiple step protocol to: (i) UE send a preamble (e.g., in Msg1) to the base station (<NUM>), (ii) after reception of preamble, BS sends back a random access response (RAR)s (e.g., Msg2) to UE (<NUM>), (iii) UE sends back a third message (e.g., Msg3) on the UL grant indicated in the RAR containing the preamble transmitted in Msg1 (<NUM>), and (iv) After successfully decoding Msg3, a fourth message (e.g., Msg4) is transmitted from the basestation to the UE for performing contention resolution (<NUM>). This example four-step random access channel protocol <NUM> may allow for establishment of RRC connections.

In some implementations, the latency created through the four-step random access protocol <NUM> (e.g., <NUM>-step RACH) may be decreased by using a two-step random access protocol <NUM> (e.g., <NUM>-step RACH). The <NUM>-step RACH <NUM> may combine (i) and (iii) and combine (ii) and (iv) to condense the RACH protocol into two steps: (a) send a first message, e.g. Msg1. In some examples the first message contains a preamble transmitted in physical random access channel and/or payload transmitted in physical uplink shared channel, which contains at least the same amount of information that is carried in Msg3 of <NUM>-step RACH (b) A second message, e.g. Msg2 in respond to Msg1 is transmitted from BS to UE. Thus, the combination of the two UE messages allows for the combination of the two basestation messages. The example <NUM>-step RACH may allow for reduced latency compared to the <NUM>-step RACH, which may reduce channel occupancy times increase data available for payload transmission or have other technical benefits. Accordingly, implementing a <NUM>-step RACH is a technical solution to a technical problem of increasing data network performance thereby improving the operation of the underlying hardware.

In various systems to implement a RACH protocol, and in some cases specifically a <NUM>-step RACH, the architecture (e.g., the header/body structure of the messages and the fields therein) of the random access messages. Although in the examples discussed in this disclosure the architectures and techniques are used in the context of a reply message (e.g., Msg2) of a <NUM>-step RACH, the architectures and techniques discussed herein may be applied to other random access messages where message architecture and content may be used to distinguish among message types. within the may be selected to support the identification of multiple different Msg2 content when received by the UE. For example, the basestation may use various message architectures to distinguish among random access messages including (e.g., in the mobile communications context) backoff indicators, success random access responses (RARs), fallback RARs, signal radio bearer (SRB) messages, arbitration messages or other random access messages. Distinguishing among messages at least in part via architecture (e.g., rather than exclusive use of message payload), may allow for faster identification, decoding, processing, and handling of random access messages. Accordingly, the use of fields and/or message structure to distinguish a technical solution to a technical problem of increasing data network performance thereby improving the operation of the underlying hardware.

<FIG> shows example random access messages <NUM>, <NUM>, <NUM>, <NUM>. The random access message in this patent refer to MAC subPDU, which will be transmitted from NW to UE as response of the reception of first message of RACH procedure. The example random access messages, including an example success RAR message <NUM>, an example fallback RAR message <NUM>, an example backoff indicator <NUM>, and an example signal radio bearer message <NUM>, may include various combinations of headers <NUM> and/or message bodies <NUM>. The random access messages <NUM>, <NUM>, <NUM>, <NUM> may include example extension fields E <NUM>, example Type <NUM> fields (T1) <NUM> example type <NUM> fields (T2) <NUM>, and example format flags (F) <NUM>. The example message includes preamble index <NUM>, timing advance command fields <NUM>, uplink grants <NUM>, UE contention resolution identifiers <NUM>, backoff indicators <NUM>, signal radio bearer (SRB) fields <NUM> and signal radio bearer parameters <NUM> (which may include any or all of: parameters to indicate the length of the SRB Service Data Unit (SDU), the SRB type, the logical channel (LCH) that carries the SRB SDU) and/or combinations thereof. Other fields may be present. The combination (including their presence and/or absence) of the example type <NUM> fields (T1) <NUM> example type <NUM> fields (T2) <NUM>, and example format flags (F) <NUM> may indicate which of the preamble indices <NUM>, UL grants fields <NUM>, contention messages <NUM>, backoff indicators <NUM>, signal radio bearer messages/parameters <NUM> and/or combinations thereof may be included within the messages. Different architectures using various combinations of the example type <NUM> fields (T1) <NUM> example type <NUM> fields (T2) <NUM>, and example format flags (F) <NUM> may distinguish among the content options. Further, various ones of the type <NUM> fields (T1) <NUM> example type <NUM> fields (T2) <NUM>, and example format flags (F) <NUM> may be included in the headers <NUM> or moved to the message bodies <NUM> in various example architectures. Further, different architectures using various combination of parameters included in signal radio bearer parameters <NUM> maybe included in the headers <NUM> or moved to the message bodies <NUM>. Further, contention messages <NUM> can be moved to the message bodies <NUM>.

In the various examples, by implementing the various ones of the type <NUM> fields (T1) <NUM>, example type <NUM> fields (T2) <NUM>, and example format flags (F) <NUM> in accord with defined rules, the basestation may ensure that UE is able to identify the content and type of the random access message to allow for efficient decoding and handling.

In the examples messages the particular configurations of Type <NUM> fields (T1) <NUM> example type <NUM> fields (T2) <NUM>, and example format flags (F) <NUM> are examples. Other configurations may be used. While other configurations are possible, including some implementations represented in the six Example Implementations discussed below, the examples <NUM>, <NUM>, <NUM>, <NUM> illustrate, that message architecture rules (e.g., the message structure, field presence/absence, and/or field content) may be linked to message type and content for identification of messages.

In the examples, the T1 field may indicate the absence or presence of the T2 field. The T2 field may distinguish among various random access message types with its content. The T2 field distinguish among an additional access message type with its absence or presence. The F flag may further distinguish among types. In some cases, the T2 field may be expanded to distinguish among options identified by T1 or F field content (e.g., and the T1 and/or F fields may be omitted or included for redundancy). In some cases, the treatment of the content of the T2 field (or "T" field when the only one "type" field is used in a particular protocol) may be conditional. In an example context using backoff indicators, the T field may be replaced by a backoff validity status indicator that indicates whether a backoff indicator in the same random access message should be ignored. However, the treatment T field may be non-conditional in various other implementations using backoff indicators. In the examples, the E field may be included to designate whether a particular random access message is a final message in a data unit (e.g., a LTE and/or <NUM> protocol data unit) or if additional messages are included after the random access message.

In some implementations, when the type <NUM> field indicates the type <NUM> field is not present, the random access message may be a fallback RAR. Accordingly, the type <NUM> field may distinguish among messages including backoff indicators, success RARs (which may include a preamble index), and signal radio bearer messages. In some cases, the type <NUM> and type <NUM> fields may be included in the message header portion of the random access message. In some cases, backoff indictor type random access messages may not necessarily include a message body portion.

In various other implementations, the type <NUM> field indicating that the type <NUM> field is not present, may indicate that the random access message is backoff indicator, success RAR, or signal radio bearer message. Accordingly, the type <NUM> field may distinguish among the other three types.

In various implementations, a success RAR message may be combined with a signal radio bearer message. In some cases, the body of success RAR messages may including F flags to indicate whether the success RAR message includes a signal radio bearer message. In some cases, the F flag may be included in the header. In some cases, the basestation may broadcast or dedicated signal an indicator to UEs indicating whether or not success RAR messages may include signal radio bearer messages. In some cases, when combined success RAR message / signal radio bearer messages are used, the T field may distinguish among fewer options due to the combination of message types. In some cases, the F flag may be omitted and its function may be performed by the T field.

<FIG> shows an illustrative examples of random access messages in an example media access control (MAC) PDU <NUM> in a LTE/<NUM> context, where the random access message refer to MAC subPDU. The media access control (MAC) PDU may include multiple random access messages for different UEs. The example MAC PDU <NUM> includes an example backoff indicator <NUM> in a first sub-PDU with a subheader <NUM>, an example success RAR <NUM> in a second sub-PDU with a subheader <NUM> and body <NUM>, an example signal radio bearer (SRB) <NUM> in a third sub-PDU with a subheader <NUM> and body <NUM>, and an example fallback RAR <NUM> in a fourth sub-PDU with a subheader <NUM> and body <NUM>. The MAC PDU <NUM> includes other sub-PDUs <NUM> and optional padding <NUM>. The example is illustrative of content options for MAC PDUs. However, the content of MAC PDUs and the location of MAC subPDUs in the MAC PDUs may change situationally responsive to UE requests. For example, some or all of the backoff indicator <NUM>, success RAR <NUM>, SRB <NUM>, and fallback RAR <NUM> may be omitted from any given MAC PDU sent by a basestation if no requests relevant to a particular message type are made by UEs.

The methods, devices, processing, circuitry, and logic described above and below may be implemented in many different ways and in many different combinations of hardware and software. For example, all or parts of the implementations may be circuitry that includes an instruction processor, such as a Central Processing Unit (CPU), microcontroller, or a microprocessor; or as an Application Specific Integrated Circuit (ASIC), Programmable Logic Device (PLD), or Field Programmable Gate Array (FPGA); or as circuitry that includes discrete logic or other circuit components, including analog circuit components, digital circuit components or both; or any combination thereof. The circuitry may include discrete interconnected hardware components or may be combined on a single integrated circuit die, distributed among multiple integrated circuit dies, or implemented in a Multiple Chip Module (MCM) of multiple integrated circuit dies in a common package, as examples.

Accordingly, the circuitry may store or access instructions for execution, or may implement its functionality in hardware alone. The instructions may be stored in tangible storage media that is other than a transitory signal, such as a flash memory, a Random Access Memory (RAM), a Read Only Memory (ROM), an Erasable Programmable Read Only Memory (EPROM); or on a magnetic or optical disc, such as a Compact Disc Read Only Memory (CDROM), Hard Disk Drive (HDD), or other magnetic or optical disk; or in or on other machine-readable media. The media may be made-up of a single (e.g., unitary) storage device, multiple storage devices, a distributed storage device, or other storage configuration. A product, such as a computer program product, may include storage media and instructions stored in or on the media, and the instructions when executed by the circuitry in a device may cause the device to implement any of the processing described above or illustrated in the drawings.

The implementations may be distributed. For instance, the circuitry may include multiple distinct system components, such as multiple processors and memories, and may span multiple distributed processing systems. Parameters, databases, and other data structures may be separately stored and managed, may be incorporated into a single memory or database, may be logically and physically organized in many different ways, and may be implemented in many different ways. Example implementations include linked lists, program variables, hash tables, arrays, records (e.g., database records), objects, and implicit storage mechanisms. Instructions may form parts (e.g., subroutines or other code sections) of a single program, may form multiple separate programs, may be distributed across multiple memories and processors, and may be implemented in many different ways. Example implementations include stand-alone programs, and as part of a library, such as a shared library like a Dynamic Link Library (DLL). The library, for example, may contain shared data and one or more shared programs that include instructions that perform any of the processing described above or illustrated in the drawings, when executed by the circuitry.

The example implementations (discussed below are included for the purposes of example illustration of the techniques and architectures discussed. The principles illustrated in the example implementations may be applied separately, combined, or in different contexts from those of the example implementation. For example, various ones of the implementations discussed below are discussed in the context of <NUM> mobile communication standards. However, the principles may be applied to other mobile communication standards.

Format for a MAC subheader of Msg2 sent in response to a Msg1 in a two-step RACH:.

The bit values (and respective logical meanings) shown in table are examples. However, logical meanings may be assigned to other bit values.

<FIG> shows an example one octet (e.g., <NUM>-bits) BI subheader <NUM>, an example one octet fallback RAR subheader <NUM>, an example two-octet success RAR subheader <NUM> using a RAPID, an example multi-octet success RAR subheader <NUM> using UE CRID, and an example two-octet SRB subheader <NUM>.

Format for a MAC payload of Msg2 sent in response to a Msg1 in a two-step RACH:.

<FIG> shows an example multiple-octet success RAR body when RAPID is included in the subheader <NUM> and an example multiple-octet success RAR body when UE CRID is included in the subheader <NUM>.

The SRB message body may include a SRB field with a length in accord with that indicated in the length field of the SRB message header.

<FIG> shows an example multiple-octet SRB message body <NUM> and an example multiple-octet fallback RAR body <NUM>.

In some cases of example implementation <NUM>, the Msg2 MAC PDU consists of one or more MAC subPDUs and optionally padding. Each MAC subPDU consists one of the following:.

Or in another cases of example implementation <NUM>, the Msg2 MAC PDU consists of one or more MAC subPDUs and optionally padding. Each MAC subPDU consists one of the following:.

For the examples given in example implementation <NUM>, if a SRB SDU with subheader is presented (e.g., the SRB SDU will be encapsulated as a separate MAC subPDU), the corresponding MAC subPDU with SRB SDU shall be located after the corresponding success RAR for the same UE.

Format for a MAC subheader sent in response to a UE message in a two-step RACH:.

<FIG> shows an example two-octet success RAR subheader <NUM> using a RAPID and without SRB, an example multi-octet success RAR subheader <NUM> using UE CRIDs and without SRB, an example two-octet success RAR subheader <NUM> using a RAPID and with SRB, an example multi-octet success RAR subheader <NUM> using UE CRIDs and with SRB.

<FIG> shows an example multiple-octet success RAR body when RAPID is included in the subheader with SRB <NUM> and an multiple-octet success RAR body when UE CRID is included in the subheader with SRB <NUM>. The subheader and body for the BI indictor, the subheader and body for the fallback RAR, the body for the success RAR using RAPID in subheader without SRB, and the body for the success RAR using UE CRID in subheader without SRB have the same formats as their analogs in Example Implementation <NUM>.

In some cases of example implementation <NUM>, the Msg2 MAC PDU consists of one or more MAC subPDUs and optional padding. The MAC subPDUs may include one of the following:.

In this example, the MAC subheader for the success RAR contains RAPID.

In this example, the MAC subheader identifying success RAR contains UE Contention Resolution ID.

In this example implementation, a combined success RAR / SRB message is used. In addition, a type field is included in the header and a second RAR type field is included in the message body for RAR messages (both fallback and success RARs). RAPID is used for success RARs to allow for consistent subheaders with fallback RARs. The F flag, L field, and LCH Ind field are moved to the message body for success RARs.

<FIG> shows an example one-octet BI subheader <NUM> and an example one-octet RAR subheader <NUM>.

<FIG> shows an example multiple-octet success RAR body with SRB <NUM> and an example multiple-octet success RAR body without SRB <NUM>.

Alternatively or additionally, the L field can be move to the front of the message body. Using the L field, the UE can identify the next MAC subPDU with the initial bits of the subPDU. <FIG> shows an example message body <NUM> for a success RAR with SRB including an L field in the first and second octets and an example message body <NUM> without SRB.

In some cases of example implementation <NUM>, the Msg2 MAC PDU includes of one or more MAC subPDUs and optional padding. The MAC subPDU may include any or all of the following:.

In this example implementation, the type field in the BI subheader is replaced with a <NUM>-bit backoff status indicator (BI Ind). The BI Ind field indicates whether the BI field should be ignored. In some cases, if BI Ind set to "<NUM>" can interpreted as the BI indicator included is invalid and UE set the backoff time as <NUM>. In some cases, Example Implementation <NUM> may be used where a BI subPDU is included in every Random Access Response, e.g. Msg2 of <NUM>-step RACH. In some cases, the BI subheader is may form a first subPDU of each Msg2 sent by the basestation. Each of the other subheaders may include a T field and RAPID field. The T field in the subheader may differentiate between fallback RARs and success RARs.

<FIG> shows an example one-octet BI subheader <NUM> and an example one-octet RAR subheader <NUM>. <FIG> shows an example message body <NUM> for a success RAR with SRB and an example message body <NUM> without SRB.

In some cases of example implementation <NUM>, the Msg2 MAC PDU includes one or more MAC subPDUs and optional padding. The MAC subPDUs may include any or all of the following:.

In Example Implementation <NUM>, the success RAR is combined with the SRB message like Example Implementation <NUM>. Relative to Example Implementation <NUM>, the type <NUM> field is shortened to one bit to distinguish between a BI subheader and a success RAR subheader. A F flag is included in the success RAR body to indicate whether an SRB field is present. Neither the RAPID field nor the UE CRID field is included in the success RAR subheader, the relevant field is included in the success RAR body.

<FIG> shows an example one-octet BI subheader <NUM>, an example one-octet fallback RAR subheader <NUM>, and an example one-octet success RAR subheader <NUM>.

In some cases of example implementation <NUM>, the Msg2 MAC PDU includes one or more MAC subPDUs and optional padding. The MAC subPDUs include any or all of the following:.

In Example Implementation <NUM>, MAC suhbeaders may include two octets.

The MAC subheaders for Msg2 consists the same type of header fields as in example implementation <NUM>, except the L field and LCH Ind field is moved to the payload part of RAR.

<FIG> shows an example two-octet BI subheader <NUM>, an example two-octet fallback RAR subheader <NUM>, and an example two-octet success RAR subheader <NUM>.

<FIG> shows an example success RAR message body <NUM> with SRB. For the format of the message body without SRB, refer to <FIG> item <NUM>.

In Example Implementation <NUM>, the MAC suhbeader with BI indicator has a fixed size of <NUM> byte, while other of MAC subheaders include two octets. In some cases, the BI subheader serves as the first subPDU of each MAC PDU.

<FIG> shows an example two-octet fallback RAR subheader <NUM>, an example two-octet success RAR without SRB SDU subheader <NUM>, and an example two-octet success RAR with SRB SDU subheader <NUM>. An example of a subeader with BI indicator is given in item <NUM> of <FIG>.

<FIG> shows an example success RAR message body <NUM> with SRB. For the format of the success RAR message body without SRB, refer to <FIG> item <NUM>. For the format of the fallback RAR message body, refer to <FIG> item <NUM>.

In Example Implementations <NUM>-<NUM>, the presence (or absence) of the SRB may indicated to UE by one bit indicator included in at least one of the following message:.

Accordingly, F flags may be omitted (or ignored) and two-bit T fields may be shortened to one-bit. In some cases, a two-bit T field may be reinterpreted to distinguish two options and reserve bit values:.

In Example Implementations <NUM>-<NUM>, an UL grant or/and a downlink (DL) assignment may be included in the content of the success RAR. For example, a UL grant can be included in a success RAR for the transmission of the acknowledgement. In another example, an UL grant may be included in a success RAR with an SRB field for subsequent uplink transmissions, e.g. an RRCSetupComplete transmission.

In another example, a DL assignment may be included in a success RAR without an SRB for subsequent downlink transmissions, e.g. an RRCSetup transmission.

In Example Implementations <NUM>-<NUM>, information for UL ACK transmission may be included in the content of success RAR.

In Example Implementation <NUM>-<NUM>, the LCH Indicator can be alternatively used to indicate the SRB ID of the SRB SDU.

Claim 1:
A method for performing random access by a base station, comprising:
receiving (<NUM>) a first message from a User Equipment, UE, in a Random Access procedure;
generating a second message including a random access message, the second message being responsive to the first message and the random access message including a first media access control, MAC, sub-protocol data unit, sub-PDU, having a first sub-header, wherein the first sub-header includes a type <NUM> field configured to indicate whether a type <NUM> field is present within the random access message, wherein a size of the type <NUM> field is <NUM> bit and wherein the type <NUM> field is either set to "<NUM>" to indicate the success random access response, RAR, is included in the first MAC sub-PDU in addition to the first subheader or is set to "<NUM>" to indicate that a Backoff Indicator is present; and
transmitting (<NUM>) the second message to the UE.