Apparatus and method to prioritize a random access procedure for emergency access

CROSS REFERENCE TO RELATED APPLICATIONS

0001This patent application claims the benefit of U.S. Provisional Patent Application No. 61/826,200, filed May 22, 2013, entitled “Prioritizing RA Procedure In LTE For RRC Connection Request With Emergency Establishment Cause,” which is incorporated herein by reference in its entirety.

BACKGROUND

Field

0002This application relates generally to wireless communications, including prioritizing random access procedures utilizing radio resource controller connection requests having an emergency Establishment Cause.

BRIEF DESCRIPTION OF THE DRAWINGS/FIGURES

0003The accompanying drawings, which are incorporated herein and form a part of the specification, illustrate the embodiments of the present disclosure and, together with the description, further serve to explain the principles of the embodiments and to enable a person skilled in the pertinent art to make and use the embodiments.

0004<figref idref="DRAWINGS">FIG. 1</figref> illustrates an example network environment.

0005<figref idref="DRAWINGS">FIG. 2</figref> illustrates a base station according to an exemplary embodiment of the present disclosure.

0006<figref idref="DRAWINGS">FIG. 3</figref> illustrates a mobile device according to an exemplary embodiment of the present disclosure.

0007<figref idref="DRAWINGS">FIG. 4</figref> illustrates a mobile device according to an exemplary embodiment of the present disclosure.

0008<figref idref="DRAWINGS">FIG. 5</figref> illustrates a flowchart of a random access procedure according to an exemplary embodiment of the present disclosure.

0009<figref idref="DRAWINGS">FIG. 6</figref> illustrates a flowchart of a transmission power adjustment method according to an exemplary embodiment of the present disclosure.

0010<figref idref="DRAWINGS">FIG. 7</figref> illustrates a flowchart of a random access procedure according to an exemplary embodiment of the present disclosure.

0011The embodiments of the present disclosure well be described with reference to the accompanying drawings. The drawing in which an element first appears is typically indicated by the leftmost digit(s) in the corresponding reference number.

DETAILED DESCRIPTION

0012In the following description, numerous specific details are set forth in order to provide a thorough understanding of the embodiments of the present disclosure. However, it will be apparent to those skilled in the art that the embodiments, including structures, systems, and methods, may be practiced without these specific details. The description and representation herein are the common means used by those experienced or skilled in the art to most effectively convey the substance of their work to others skilled in the art. In other instances, well-known methods, procedures, components, and circuitry have not been described in detail to avoid unnecessarily obscuring aspects of the disclosure.

0013In the following disclosure, terms defined by the Long-Term Evolution (LTE) standard are sometimes used. For example, the term “eNodeB” or “eNB” is used to refer to what is commonly described as a base station (BS) or a base transceiver station (BTS) in other standards. The term “User Equipment (UE)” is used to refer to what is commonly described as a mobile station (MS) or mobile terminal in other standards. The LTE standard is developed by the 3rd Generation Partnership Project (3GPP) and described in the 3GPP specification and International Mobile Telecomunnications-2000 (IMT-2000) standard, all of which are incorporated by reference in their entirety. Further, 3GPP refers to a communication network as a UTRAN (Universal Mobile Telecommunication System (UMTS) Terrestrial Radio Access Network, a E-UTRAN (Evolved UTRAN), and/or a GERAN (Global System for Mobile Communications (GSM) Enhanced Data rates for GSM Evolution (EDGE) Radio Access Network) to provide some examples.

0014Although exemplary embodiments are described with reference to LTE, the more generic terms “mobile device” and “base station” are used herein except where otherwise noted to refer to the LTE terms “User Equipment (UE)” and “eNodeB/eNB,” respectively. Further, the embodiments are not limited to implementation in LTE, as other communication standards could be used, as will be understood by those skilled in the arts.

0015As will be apparent to one of ordinary skill in the relevant art(s) based on the teachings herein, exemplary embodiments are not limited to the LTE standard, and can be applied to other cellular communication standards, including (but not limited to) Evolved High-Speed Packet Access (HSPA+), Wideband Code Division Multiple Access (W-CDMA), CDMA2000, Time Division-Synchronous Code Division Multiple Access (TD-SCDMA), Global System for Mobile Communications (GSM), General Packet Radio Service (GPRS), Enhanced Data Rates for GSM Evolution (EDGE), and Worldwide Interoperability for Microwave Access (WiMAX) (IEEE 802.16) to provide some examples. Further, exemplary embodiments are not limited to cellular communication networks and can be used or implemented in other kinds of wireless communication access networks, including (but not limited to) Wireless Local Area Network (WLAN [IEEE 802.11]), Bluetooth (IEEE 802.15.1 and Bluetooth Special Interest Group (SIG)), Near-field Communication (NFC) (ISO/IEC 18092), ZigBee (IEEE 802.15.4), Radio-frequency identification (RFID), and/or infrared communication, to provide some examples. These various standards and/or protocols are each incorporated by reference in their entirety.

0016For the purposes of this discussion, the term “processor circuitry” shall be understood to be one or more: circuit(s), processor(s), or a combination thereof. For example, a circuit can include an analog circuit, a digital circuit, state machine logic, other structural electronic hardware, or a combination thereof. A processor can include a microprocessor, a digital signal processor (DSP), or other hardware processor. The processor can be “hard-coded” with instructions to perform corresponding function(s) according to embodiments described herein. Alternatively, the processor can access an internal and/or external memory to retrieve instructions stored in the memory, which when executed by the processor, perform the corresponding function(s) associated with the processor.

0017<figref idref="DRAWINGS">FIG. 1</figref> illustrates an example communication environment <b>100</b> that includes one or more base stations <b>120</b> and one or more mobile devices <b>140</b>. The base station(s) <b>120</b> and mobile device(s) <b>140</b> each include one or more processors, circuitry, and/or logic that is configured to communicate via one or more wireless technologies. The one or more processors can include (and be configured to access) one or more internal and/or external memories that store instructions and/or code that, when executed by the processor(s), cause the processor(s) to perform one or more operations to facilitate communications via one or more wireless technologies as discussed herein. Further, one or more of the mobile devices <b>140</b> can be configured to support co-existing wireless communications. The mobile device(s) <b>140</b> can include, for example, a transceiver having one or more processors, circuitry, and/or logic that is configured to transmit and/or receive wireless communications via one or more wireless technologies within the communication environment <b>100</b>. The base station(s) <b>120</b> include one or more processors, circuitry, and/or logic that is configured to: (1) receive one or more wired communications via one or more well-known wired technologies (e.g., within a core (backhaul) network <b>125</b>) and transmit one or more corresponding wireless communications via one or more wireless technologies within the communication environment <b>100</b>, (2) receive one or more wireless communications within the communication environment <b>100</b> via one or more wireless technologies and transmit one or more corresponding wired communications via one or more well-known wired technologies within a core network, and (3) to transmit and/or receive wireless communications via one or more wireless technologies within the communication environment <b>100</b>. The wireless technologies can include, for example, one or more wireless protocols discussed above. The number of mobile devices <b>140</b> and/or base stations <b>120</b> are not limited to the numbers shown in the exemplary embodiment illustrated in <figref idref="DRAWINGS">FIG. 1</figref>, and the communication environment <b>100</b> can include any number of mobile devices <b>140</b> and/or base stations <b>120</b> as would be understood by those skilled in the relevant arts without departing from the spirit and scope of the present disclosure.

0018The mobile device <b>140</b> can be configured to communicate with the base station <b>120</b> in a serving cell or sector <b>110</b> of the communication environment <b>100</b>. For example, the mobile device <b>140</b> receives signals on one or more downlink (DL) channels and transmits signals to the base station <b>120</b> on one or more respective uplink (UL) channels. The mobile device <b>140</b> can also be configured to communicate with one or more other mobile devices <b>140</b> utilizing one or more device-to-device communication connections (e.g., using Bluetooth, Wi-Fi, etc.).

0019Examples of the mobile device <b>140</b> include (but are not limited to) a mobile computing device—such as a laptop computer, a tablet computer, a mobile telephone or smartphone, a “phablet,” a personal digital assistant (PDA), and mobile media player; and a wearable computing device—such as a computerized wrist watch or “smart” watch, and computerized eyeglasses. In some embodiments, the mobile device <b>140</b> may be a stationary device, including, for example, a stationary computing device—such as a personal computer (PC), a desktop computer, a computerized kiosk, and an automotive/aeronautical/maritime in-dash computer terminal.

0020In an exemplary embodiment, the base station <b>120</b> includes one or more processors, circuitry, and/or logic that is configured for communications conforming to 3GPP's Long-Term Evolution (LTE) specification (e.g., the base station is an LTE base station), and the mobile device <b>140</b> includes one or more processors, circuitry, and/or logic that is configured for communications conforming to 3GPP's LTE specification. The one or more processors, circuitry, and/or logic of the mobile device <b>140</b> can be further configured for communications conforming to one or more other 3GPP and/or non-3GPP protocols via one or more device-to-device communication networks established with one or more other mobile devices. In this example, the serving cell or sector <b>110</b> is an LTE serving cell or sector. In an exemplary embodiment, the communication of the mobile device <b>140</b> with one or more other mobile devices <b>140</b> can be a device-to-device communication that bypasses the base station <b>120</b>.

0021Those skilled in the relevant art(s) will understand that the base station(s) <b>120</b> and the mobile device(s) <b>140</b> are not limited to the exemplary 3GPP and non-3GPP wireless protocols discussed herein, and the base station(s) <b>120</b> and/or the mobile device(s) <b>140</b> can be configured for wireless communications conforming to one or more other 3GPP and/or non-3GPP wireless protocols in addition to, or in the alternative to, the wireless protocols discussed herein.

0022<figref idref="DRAWINGS">FIG. 2</figref> illustrates the base station <b>120</b> according to an exemplary embodiment of the present disclosure. For example, the base station <b>120</b> can include a transceiver <b>200</b> communicatively coupled to processor circuitry <b>240</b>.

0023The transceiver <b>200</b> includes one or more processors, circuitry, and/or logic that is configured to transmit and/or receive wireless communications via one or more wireless technologies within the communication environment <b>100</b>. In particular, the transceiver <b>200</b> can include a transmitter <b>210</b> and a receiver <b>220</b> that have one or more processors, circuitry, and/or logic configured to transmit and receive wireless communications, respectively, via one or more antennas <b>230</b>. Those skilled in the relevant art(s) will recognize that the transceiver <b>200</b> can also include (but is not limited to) a digital signal processer (DSP), modulator and/or demodulator, a digital-to-analog converter (DAC) and/or an analog-to-digital converter (ADC), and/or a frequency converter (including mixers, local oscillators, and filters) to provide some examples. Further, those skilled in the relevant art(s) will recognize that the antenna <b>230</b> may include an integer array of antennas, and that the antenna <b>230</b> may be capable of both transmitting and receiving wireless communication signals. For example, the base station <b>120</b> can be configured for wireless communication utilizing a Multiple-input Multiple-output (MIMO) configuration.

0024In an exemplary embodiment, the transceiver <b>200</b> is configured for wireless communications conforming to one or more wireless protocols defined by 3GPP. For example, the transceiver <b>200</b> is configured for wireless communications conforming to 3GPP's LTE specification. In this example, the transceiver <b>200</b> can be referred to as LTE transceiver <b>200</b>. Those skilled in the relevant art(s) will understand that the transceiver <b>200</b> is not limited to communication conforming to 3GPP's LTE specification, and can be configured for communications that conform to one or more other 3GPP protocols and/or one or more non-3GPP protocols. It should be appreciated that the transceiver <b>200</b> can be referred to by one or more other 3GPP and/or non-3GPP protocols in embodiments where the transceiver <b>200</b> is configured for such other communications conforming to the other 3GPP and/or non-3GPP protocols.

0025The processor circuitry <b>240</b> can include one or more processors (CPUs) <b>250</b> and/or circuits configured to carry out instructions to perform arithmetical, logical, and/or input/output (I/O) operations of the base station <b>120</b> and/or one or more components of the base station <b>120</b>. The processor circuitry <b>240</b> can further include a memory <b>260</b> that stores data and/or instructions, where when the instructions are executed by the processor(s) <b>250</b>, perform the functions described herein. The memory <b>260</b> can be any well-known volatile and/or non-volatile memory, including, for example, read-only memory (ROM), random access memory (RAM), flash memory, a magnetic storage media, an optical disc, erasable programmable read only memory (EPROM), and programmable read only memory (PROM). The memory <b>260</b> can be non-removable, removable, or a combination of both.

0026<figref idref="DRAWINGS">FIG. 3</figref> illustrates the mobile device <b>140</b> according to an exemplary embodiment of the present disclosure. The mobile device <b>140</b> can include processor circuitry <b>340</b> communicatively coupled to one or more transceivers configured to communicate with one or more 3GPP and/or non-3GPP communication protocols. That is, the mobile device <b>140</b> can be configured for wireless communications conforming to one or more wireless protocols defined by 3GPP and/or one or more non-3GPP wireless protocols. In an exemplary embodiment, the mobile device <b>140</b> includes an LTE transceiver <b>300</b> and a WLAN transceiver <b>330</b>. In this example, the mobile device <b>140</b> is configured for wireless communication conforming to 3GPP's LTE specification and for wireless communication conforming to IEEE's 802.11 WLAN specification. Those skilled in the relevant art(s) will understand that the mobile device <b>140</b> is not limited to these exemplary 3GPP and non-3GPP wireless protocols, and the mobile device <b>140</b> can be configured for wireless communications conforming to one or more other 3GPP and/or non-3GPP wireless protocols in addition to, or in the alternative to, the wireless protocols discussed herein, and/or to a subset of the LTE and WLAN specifications discussed above.

0027The LTE transceiver <b>300</b> includes one or more processors, circuitry, and/or logic that is configured for transmitting and/or receiving wireless communications conforming to 3GPP's LTE specification. In particular, the LTE transceiver <b>300</b> can include an LTE transmitter <b>310</b> and an LTE receiver <b>320</b> that have one or more processors, circuitry, and/or logic configured for transmitting and receiving wireless communications conforming to 3GPP's LTE specification, respectively, via one or more antennas <b>335</b>. Transceiver <b>300</b> need not be limited to LTE, and could operate according to one or more other 3GPP and/or non-3GPP protocols, as will be understood by those skilled in art.

0028The WLAN transceiver <b>330</b> includes one or more processors, circuitry, and/or logic that is configured for transmitting and/or receiving wireless communications conforming to IEEE's 802.11 WLAN specification. In particular, the WLAN transceiver <b>330</b> can include a WLAN transmitter <b>315</b> and a WLAN receiver <b>325</b> that have one or more processors, circuitry, and/or logic configured for transmitting and receiving wireless communications conforming to IEEE's 802.11 WLAN specification, respectively, via one or more antennas <b>345</b>. Transceiver <b>330</b> need not be limited to WLAN, and could operate according to one or more other 3GPP and/or non-3GPP protocols, as will be understood by those skilled in art.

0029In exemplary embodiments, the LTE transceiver <b>300</b> and the WLAN transceiver <b>330</b> can include (but are not limited to) a digital signal processer (DSP), modulator and/or demodulator, a digital-to-analog converter (DAC) and/or an analog-to-digital converter (ADC), and/or a frequency converter (including mixers, local oscillators, and filters) that can be utilized in transmitting and/or receiving of wireless communications. Further, those skilled in the relevant art(s) will recognize that antennas <b>335</b> and/or <b>345</b> may include an integer array of antennas, and that the antennas may be capable of both transmitting and receiving wireless communication signals. It will also be understood by those skilled in the relevant art(s) that any combination of the LTE transceiver <b>300</b> and WLAN transceiver <b>330</b>, as well as one or more other transceivers, circuits, and/or processors may be embodied in a single chip and/or die.

0030The processor circuitry <b>340</b> includes one or more processors, circuitry, and/or logic that is configured to control the overall operation of the mobile device <b>140</b>, including the operation of the LTE transceiver <b>300</b> and WLAN transceiver <b>330</b>. The one or more processors can include one or more baseband processors <b>350</b>, one or more application processors <b>370</b>, and/or one or more other processors (CPUs) <b>380</b>. As would be understood by those skilled in the relevant arts, any combination of the baseband processor(s) <b>350</b>, application processor(s) <b>370</b> and/or processor(s) <b>380</b> may be embodied as a single chip and/or die.

0031The processor circuitry <b>340</b> can further include a memory <b>360</b> that stores data and/or instructions, where when the instructions are executed by the processor(s) <b>350</b>, baseband processor(s) <b>370</b>, and/or application processor(s) <b>380</b>, to perform the functions described herein. Similarly, the memory <b>360</b> can be any well-known volatile and/or non-volatile memory, and can be non-removable, removable, or a combination of both.

0032The baseband processor(s) <b>350</b> can be configured to control the operation of the LTE transceiver <b>300</b> and/or WLAN transceiver <b>330</b>, including transmitting and/or receiving of wireless communications via the LTE transceiver <b>300</b> and/or WLAN transceiver <b>330</b>, and/or perform one or more baseband processing functions, including (but not limited to), for example, media access control (MAC), encoding/decoding, modulation/demodulation, data symbol mapping, error correction, and the like.

0033The application processor(s) <b>370</b> can be configured to carry out instructions to perform arithmetical, logical, and/or input/output (I/O) operations of the mobile device <b>140</b> and/or of one or more components of the mobile device <b>140</b>. For example, the application processor(s) <b>370</b> can be configured to carry out internally-stored instructions and/or instructions stored in memory <b>360</b>, including the running of one or more applications and/or operating systems, including user selected applications.

0034The processor(s) <b>380</b> can be configured to control the operation of the mobile device <b>140</b>, including carrying out one or more instructions to perform one or more functions described herein.

0035In an exemplary embodiment, the mobile device <b>140</b> includes one or more other transceivers (not shown) configured to communicate via one or more 3GPP protocols, one or more non-3GPP protocols, and/or one or more other well-known communication technologies. In an exemplary embodiment, the one or more other transceivers can be configured for navigational purposes utilizing one or more well-known navigational systems, including the Global Navigation Satellite System (GNSS), the Russian Global Navigation Satellite System (GLONASS), the European Union Galileo positioning system (GALILEO), the Japanese Quasi-Zenith Satellite System (QZSS), the Chinese BeiDou navigation system, and/or the Indian Regional Navigational Satellite System (IRNSS) to provide some examples.

0036Further, the mobile device <b>140</b> can include one or more positional and/or movement sensors <b>390</b> (e.g., GPS, accelerometer, gyroscope sensor, etc.) implemented in (and/or in communication with) the mobile device <b>140</b>. Here, the location and/or movement of the mobile device <b>140</b> can be determined using one or more transceivers configured for navigation purposes, one or more of the positional and/or movement sensors <b>390</b>, and/or one or more positional determinations using signal characteristics relative to one or more base stations and/or access points.

0037<figref idref="DRAWINGS">FIG. 4</figref> illustrates a description of the mobile device <b>140</b> in accordance with an exemplary embodiment of the present disclosure, where the mobile device <b>140</b> can include an architecture having various layers (in order of highest to lowest in the architecture): Non-Access Stratum (NAS) layer, Radio Resource Control (RRC) layer, Media Access Control (MAC) layer, and Physical (PHY) layer. The architecture is not limited to these exemplary layers and can include one or more other layers as would be understood by those skilled in the relevant arts. In exemplary embodiments, the various layers can be implemented in one or more components of the mobile device <b>140</b>, including, for example, in one or more of the processors and/or transceivers of the mobile device <b>140</b>. More specifically, one or more of the layers can be implemented in, for example, the baseband processor(s) <b>350</b> and/or transceivers <b>300</b>/<b>330</b>, while one or more other layers can be implemented in the application processor(s) <b>370</b>. In an exemplary embodiment, the PHY layer is implemented in one or more transceivers <b>300</b>, <b>330</b> and the MAC layer is implemented in the baseband processor(s) <b>350</b>, and the RRC layer and the NAS layer are implemented in the application processor(s) <b>370</b> and/or processor(s) <b>380</b>. The implementation of the various layers within the mobile device <b>140</b> are not limited to these exemplary implementations, and the various layers of the architecture can be implemented in any combination of processors and/or transceivers of the mobile device <b>140</b> as would be understood by those skilled in the relevant arts.

0038As set forth in one or more 3GPP's LTE specifications, the physical layer of LTE utilizes orthogonal frequency division multiplexing (OFDM) for the downlink (DL) and single carrier frequency division multiplexing (SC-FDM) for the uplink (UL). According to the LTE specification, the downlink and uplink transmissions are organized into radio frames each having a duration of 10 millisecond (ms). Here, a radio frame consists of 10 subframes, each subframe consisting of two consecutive 0.5 ms slots. Each slot comprises six OFDM symbols for an extended cyclic prefix and seven OFDM symbols for a normal cyclic prefix. In both the uplink and downlink, data is time and frequency multiplexed by mapping OFDM symbols to a time/frequency resource grid consisting of elementary units called resource elements (REs) that are uniquely identified by the antenna port, sub-carrier position, and OFDM symbol index within a radio frame. A group of resource elements corresponding to twelve consecutive subcarriers within a single time slot is referred to as a resource block (RB). The one or more 3GPP LTE specifications include the European Telecommunications Standard Institute (ETSI) Technical Specification (TS) 136 Series, referred hereinafter as “3GPP TS 36 Series,” each of which is incorporated herein by reference in its entirety.

0039In an exemplary embodiment, and as explained in detail below, the mobile device <b>140</b> (e.g., UE) is configured to acquire uplink (UL) resources from the base station <b>120</b> (e.g., eNB) for transmitting data by performing a random access (RA) procedure using the physical random access channel (PRACH). The PRACH defines time-frequency resources allocated by the base station <b>120</b> for use by mobile device <b>140</b> in performing the RA procedure. The mobile device <b>140</b> can also be configured to use the random access (RA) procedure to acquire uplink resources for subsequent data transmission, typically when periodic scheduling request (SR) resources are not allocated to the mobile device <b>140</b> by the communication environment <b>100</b>. The PRACH resources are shared among mobile devices <b>140</b> operating in a connected mode and mobile devices <b>140</b> operating in an idle mode. In operation, the communication environment <b>100</b> can be configured to perform back-off operations in response to collisions between mobile devices <b>140</b> utilizing the PRACH resources.

0040When the mobile device <b>140</b> (e.g., UE) is in a connected state, uplink and downlink resources are allocated by the base station <b>120</b> (e.g., eNB). In this example, the allocation of downlink resources by the base station <b>120</b> can be referred to as “downlink synchronization.” At the physical level (e.g., PHY layer), the uplink and downlink resources are segregated into separate physical channels. The mobile device <b>140</b> is allocated resources in the physical uplink control channel (PUCCH) for requesting resources for transmitting data to the base station <b>120</b> over the physical uplink shared channel (PUSCH). If the mobile device <b>140</b> has not been allocated resources on the PUCCH for transmitting such a scheduling request, the mobile device <b>140</b> may use a random access (RA) procedure for the scheduling request.

0041In performing a random access (RA) procedure, the base station <b>120</b> is configured to reserve time-frequency resources for use by the mobile device <b>140</b>. These resources are referred to as the physical random access channel (PRACH). In operation, the base station <b>120</b> broadcasts the location of the PRACH in the time-frequency grid to the mobile devices <b>140</b> in a system information block (SIB) message. The mobile device <b>140</b> can be configured to utilize a random access procedure for several purposes, including, for example: initial access to establish a connection with the base station <b>120</b>, transitioning from an idle state to a connected state, establishing or re-establishing synchronization with the base station <b>120</b>, and/or during a handover process to a new cell. In exemplary embodiments, and as discussed in more detail below, the mobile device <b>140</b> can be configured to utilize a random access procedure to perform an emergency call.

0042Random access procedures are discussed in detail in European Telecommunications Standard Institute (ETSI) Technical Specification (TS) 136 321 V103.0 (2013-02) (LTE; Evolved Universal Terrestrial Radio Access (E-UTRA); Medium Access Control (MAC) protocol specification), referred hereinafter as “3GPP TS 36.321,” which is incorporated herein by reference in its entirety.

0043A random access procedure can be initiated by an instruction received over the physical downlink control channel (PDCCH) or by the medium access control (MAC) layer. For example, if the mobile device <b>140</b> receives a PDCCH transmission consistent with a PDCCH instruction, the mobile device <b>140</b> can be configured to initiate a random access procedure. In exemplary embodiments, the mobile device <b>140</b> can be configured to establish an emergency call before the institution of a random access procedure. In these examples, the mobile device <b>140</b> can configure the common control channel (CUTE) before providing a connection establishment request to the MAC layer (i.e., before the institution of a random access procedure). The configured CCCH can provide the MAC layer with an Establishment Cause that can prioritize one or more subsequent random access procedures. For example, the radio resource control (RRC) layer can be configured to provide the MAC layer with the CCCH, including the Establishment Cause, to indicate the subsequent random access procedure is to be prioritized for an emergency call.

0044In an exemplary embodiment, the common control channel (CCCH) is configured to include an Establishment Cause in addition to the various parameters that are defined in ETSI TS 136 331 V10.12.0 (2014-01), referred hereinafter as the “3GPP TS 36.331 specification,” which is incorporated herein by reference in its entirety. The CCCH configuration in accordance with an exemplary embodiment is shown below in Table 1.

0045<tables id="TABLE-US-00001" num="00001"><table frame="none" colsep="0" rowsep="0"><tgroup align="left" colsep="0" rowsep="0" cols="3"><colspec colname="1" colwidth="91pt" align="left" /><colspec colname="2" colwidth="28pt" align="center" /><colspec colname="3" colwidth="98pt" align="left" /><thead><row><entry namest="1" nameend="3" rowsep="1">TABLE 1</entry></row><row><entry namest="1" nameend="3" align="center" rowsep="1" /></row><row><entry>Parameters</entry><entry>Value</entry><entry>Description</entry></row><row><entry namest="1" nameend="3" align="center" rowsep="1" /></row></thead><tbody valign="top"><row><entry>PDCP configuration</entry><entry>N/A</entry><entry /></row><row><entry>RLC configuration</entry><entry>TM</entry></row><row><entry>MAC configuration</entry><entry /><entry>Normal MAC headers are used</entry></row><row><entry>Logical channel configuration</entry></row><row><entry>Priority</entry><entry>1</entry><entry>Highest priority</entry></row><row><entry>prioritisedBitRate</entry><entry>Infinity</entry></row><row><entry>bucketSizeDuration N/A</entry><entry>N/A</entry></row><row><entry>logicalChannelGroup 0</entry><entry>0</entry></row><row><entry>logicalChannelSR-Mask-r9</entry><entry>release</entry></row><row><entry>Establishment Cause</entry><entry>0 or 1</entry><entry>0 = Emergency Call;</entry></row><row><entry /><entry /><entry>1 = Normal operation</entry></row><row><entry namest="1" nameend="3" align="center" rowsep="1" /></row></tbody></tgroup></table></tables>

0046In exemplary embodiments, the mobile device <b>140</b> can be configured to prepare the common control channel (CCCH) to include the Establishment Cause as shown above in Table 1. The Establishment Cause can be configured in the RRC layer by the NAS layer and provided from the RRC layer to the MAC layer. The MAC layer can then prioritize a subsequent random access procedure for the establishment of an emergency call, as discussed in more detail below, utilizing the CCCH that includes the Establishment Cause.

0047As discussed above, the base station <b>120</b> is configured to reserve time-frequency resources for use by the mobile device <b>140</b>. The resources are referred to as the physical random access channel (PRACH). In operation, the base station <b>120</b> broadcasts the location of the PRACH in the time-frequency grid to the mobile devices <b>120</b> in a system information block (SIB) message.

0048In an exemplary embodiment, the PRACH is configured to identify one or more random access preambles that are to be utilized by the mobile device <b>120</b> during the random access procedure. For example, a plurality of random access preambles can be segregated into two groups: Group A and Group B. The PRACH can further identify how the preambles of each of the groups are to be utilized in the random access procedure. The selection between the groups of preambles can be based on, for example, the total number of random access preambles (numberOfRA-Preambles) and/or the number of random access preambles in Group A (sizeOfRA-PreamblesGroupA) In operation, the number of random access preambles in Group B can be identified by subtracting the number of preambles in Group A from the total number of preambles (e.g., number of preambles in Group B=numberOfRA-Preambles−sizeOfRA-PreamblesGroupA). The selection can be further based on one or more other parameters as defined in ETSI TS 136 321 V11.5.0 (2014-03), referred hereinafter as the “3GPP TS 36.321 specification,” which is incorporated herein by reference in its entirety, and/or one or more parameters as would be understood by those skilled in the relevant arts. In an exemplary embodiment, the Group A preambles can be used for initial connections to the base station <b>120</b> by the mobile devices <b>140</b> while Group B preambles can be used for random access procedures by the mobile devices <b>140</b> that have previously been connected with the base station <b>120</b> (i.e. previously served), but have been idle for a predetermined period of time.

0049In exemplary embodiments, the PRACH can identify a maximum transmission power so that the mobile devices <b>140</b> do not saturate the base station <b>120</b>, herein known as a “saturation power” (i.e., a transmission power level just below that which causes saturation at the base station). The mobile device <b>140</b> can then be configured to determine the power at which the random access channel (RACH) is to be sent out by the PHY layer to the base station <b>120</b>. The transmission power can be determined using the following equation:

0050<maths id="MATH-US-00001" num="00001"><math overflow="scroll"><mrow><mi>preambleReceivedTargetPower</mi><mo>=</mo><mrow><mi>preambleInitialReceivedTargetPower</mi><mo>+</mo><mi>DELTA_PREAMBLE</mi><mo>+</mo><mrow><mrow><mo>(</mo><mrow><mrow><mi>PREAMBLE_TRANSMISSION</mi><mo>⁢</mo><mi>_COUNTER</mi></mrow><mo>-</mo><mn>1</mn></mrow><mo>)</mo></mrow><mo>×</mo><mi>powerRampingStep</mi></mrow></mrow></mrow></math></maths><img file="US9609499B2_D0001.tif" /><br /> Where the preambleInitialReceivedTargetPower is the initial preamble power, the DELTA_PREAMBLE is the preamble format based offset, the PREAMBLE_TRANSMISSION_COUNTER is the number of preambles that have been transmitted, and the powerRampingStep is a power-ramping factor (an integer >0). In operation, the transmission power is increased for each subsequent preamble transmission attempt in increments of the powerRampingStep. For example, for the initial preamble transmission, the preambleReceivedTargetPower=preambleInitialReceivedTargetPower+DELTA_PREAMBLE as the PREAMBLE_TRANSMISSION_COUNTER initially is set one. For the next preamble transmission attempt, the value of the PREAMBLE_TRANSMISSION_COUNTER is two. Here, the value of the preambleReceivedTargetPower is increased by a single factor (e.g., 2−1=1) of the powerRampingStep. A next preamble transmission attempt would increase the transmission power by two factors (e.g., 3−1=2) of the powerRampingStep, and so on. The transmission power is discussed in detail in §5.1 of the 3GPP TS 36.321 specification.

0051In operation, to begin a random access procedure, the mobile device <b>140</b> is configured to transmit a random access preamble on the physical random access channel (PRACH). The transmission of the random access preamble initiates an exchange of messages between the mobile device <b>140</b> and the base station <b>120</b>. The exchange may either be contention-based or non-contention-based. In response to the random access procedure, the mobile device <b>120</b> receives resources for uplink transmission, an initial value for the uplink timing advance and, if it does not already have one, a C-RNTI (cell-specific radio network temporary identifier) that identifies the mobile device <b>140</b> and enables the mobile device <b>140</b> to decode information in the physical downlink control channel (PDCCH) intended for it.

0052<figref idref="DRAWINGS">FIG. 5</figref> illustrates a flowchart <b>500</b> of a random access procedure in accordance with an exemplary embodiment of the present disclosure. The method of flowchart <b>500</b> is described with continued reference to one or more of <figref idref="DRAWINGS">FIGS. 1-4</figref>. The steps of the method of flowchart <b>500</b> are not limited to the order described below, and the various steps may be performed in a different order. Further, two or more steps of the method of flowchart <b>500</b> may be performed simultaneously with each other.

0053The method of flowchart <b>500</b> begins at step <b>510</b>, where the mobile device <b>140</b> is configured to transmit a random access preamble to the base station <b>120</b> using the PRACH. In this example, the preamble transmission indicates to the base station <b>120</b> that the mobile device <b>140</b> is performing a random access procedure and also allows the base station <b>120</b> to estimate the transmission delay between the mobile device <b>140</b> and the base station <b>120</b> for adjusting uplink timing. The preamble transmission can include a Random Access Radio Network Temporary Identifier (RA-RNTI) associated with the PRACH used in the transmission of the random access preamble.

0054After step <b>510</b>, the method of flowchart <b>500</b> transitions to step <b>520</b>, where the base station <b>120</b> is configured to transmit a random access response to the mobile device <b>140</b>. The random access response includes a timing advance command that allows the mobile device <b>140</b> to adjust the timing of the mobile device's <b>140</b> uplink transmission based on the transmission delay estimate determined in step <b>510</b>. The mobile device <b>140</b> is also configured to determine uplink resources identified by the base station <b>120</b> in the random access response. The random access response is transmitted over a Physical Downlink Shared Channel (PDSCH) resource that is identified with a PDCCH transmission reserved for random access responses. The base station <b>120</b> can also be configured to include a back-off command if the base station <b>120</b> detects a collision due to multiple mobile devices <b>140</b> attempting random access procedures. The back-off command instructs the mobile device <b>140</b> to delay a subsequent random access procedure. In operation, the mobile device <b>140</b> is configured to monitor the PDCCH for a random access response identified by the Random Access Radio Network Temporary Identifier (RA-RNTI) defined in the random access preamble transmission. If the random access response contains the random access preamble identifier (e.g., RA-RNTI) corresponding to the transmitted random access preamble, the mobile device <b>140</b> determines that the random access response was successfully received. If no random access response is received by the mobile device <b>140</b> within the predetermined random access response window, or if none of the received random access responses contains the random access preamble identifier (e.g., RA-RNTI), the mobile device <b>140</b> determines that the random access response reception has been unsuccessful. In these examples, the mobile device <b>140</b> can be configured to perform random access response reception processing as defined in section 5.1.4 of the 3GPP TS 36.321 specification. For example, the mobile device <b>140</b> can return to step <b>510</b>, where the mobile device <b>140</b> is configured to increment the PREAMBLE_TRANSMISSION_COUNTER by 1, and select and transmit another random access resource (e.g., random access preamble).

0055After step <b>520</b>, the method of flowchart <b>500</b> transitions to step <b>530</b>, where the mobile device <b>140</b> is configured to transmit an identification message to the base station <b>120</b> using a Physical Uplink Shared Channel (PUSCH) resource assigned to the mobile device <b>140</b> by the base station <b>120</b> during the identification of uplink resources with the random access response. In operation, the mobile device <b>140</b> is configured to transmit the identification message in response to a successful receipt of the random access response. The mobile device <b>140</b> can be configured to await receipt of a Hybrid Automatic repeat request (HARQ) acknowledgment (ACK) from the base station <b>120</b>. The mobile device <b>140</b> determines that the identification message was successfully received by the base station <b>120</b> upon receipt of the HARQ ACK from the base station <b>120</b>. That is, the HARQ ACK acknowledges that the identification message was successfully received by the base station <b>120</b>.

0056In exemplary embodiments, the identification message may include a scheduling request by the mobile device <b>140</b>, and the identification message can be included in an msg3 message. For example, the msg3 message can include a Cell Radio Network Temporary Identifier (C-RNTI) Media Access Control (MAC) Control Element (CE) or a common control channel (CCCH) Service Data Unit (SDU), submitted from one or more upper layers and associated with the mobile device <b>140</b> Contention Resolution Identity.

0057After step <b>530</b>, the method of flowchart <b>500</b> transitions to step <b>540</b>, where the base station <b>120</b> is configured to transmit a grant message to the mobile device <b>140</b> using the PDSCH. The grant message resolves any contention due to multiple mobile devices <b>140</b> performing a random access procedure using the same preamble and receiving the same random access response from the base station <b>120</b>. Here, the mobile device <b>140</b> is granted uplink resources if the random access procedure is successful.

0058A non-contention-based random access procedure is similar to the method of flowchart <b>500</b> and would involve only steps <b>510</b> and <b>520</b> discussed above. In a non-contention-based random access procedure, the base station <b>120</b> is configured to allocate a dedicated preamble to the mobile device <b>140</b>.

0059In an exemplary embodiment, the base station <b>120</b> can be configured to segregate the plurality of random access preambles into three preamble groups. For example, the base station <b>120</b> can be configured to segregate the plurality of random access preambles into three groups: Group A, Group B, and Group C. In these examples, the PRACH is used to identify the plurality of random access preambles that are to be utilized by the mobile device <b>120</b> during the random access procedure, and the group from among the three groups each of the preambles is associated with. The PRACH can also identify how the preambles of each of the groups are to be utilized in the random access procedure.

0060In exemplary embodiments, the Group A preambles can be used for initial connections to the base station <b>120</b> by the mobile devices <b>140</b> while Group B preambles can be used for random access procedures by the mobile devices <b>140</b> that have previously been connected to the base station <b>120</b> but have been idle for a predetermined period of time. Herein, “previously connected” to the base station means that the mobile device has been previously served by the base station <b>120</b> for communications. The preambles of Group C can be used for emergency services (e.g., emergency calls). A message can be sent using the PRACH channel to identify the RA preambles to the mobile devices, and the assignment of the RA preambles to the various Groups. The functional purpose (i.e. initial connection, previous connection, emergency call) of the Groups and be provided a priori, or alternatively also provided using the PRACH channel.

0061In these exemplary embodiments, the base station <b>120</b> can identify the number of preambles in Group B (sizeOfRA-PreamblesGroupB) in addition to the number of total random access preambles (numberOfRA-Preambles) and the number of preambles in Group A (sizeOfRA-PreamblesGroupA). The set of random access preambles in Group C can be {(sizeOfRA-PreamblesGroupB), (numberOfRA-Preambles−1)}. Similarly, the set of random access preambles in Group B can be {(sizeOfRA-PreamblesGroupA), (sizeOfRA-PreamblesGroupB−1)} and the set of random access preambles in Group A can be {0, (sizeOfRA-PreamblesGroupA−1)}.

0062In operation, the base station <b>120</b> is configured to reserve time-frequency resources for use by the mobile device <b>140</b>. The resources are referred to as the physical random access channel (PRACH). In operation, the base station <b>120</b> broadcasts the location of the PRACH in the time-frequency grid to the mobile devices <b>120</b> in a system information block (SIB) message. The PRACH is used to identify one or more random access preambles that are to be utilized by the mobile device <b>120</b> during the random access procedure. In exemplary embodiments, the PRACH is used identify the three groups of random access preambles (Group A, Group B and Group C), where the preambles of Group C are utilized for emergency calls.

0063In these examples, the mobile device <b>140</b> is configured to utilize the resources identified by the PRACH in the performance of random access procedures. More specifically, the mobile device <b>140</b> can be configured to select a preamble from Group C to establish an emergency call. For example, the mobile device <b>140</b> can be configured to prepare the common control channel (CCCH) to include the Establishment Cause as discussed above and shown in Table 1. The Establishment Cause can be configured in the RRC layer by the NAS layer, and provided to the MAC layer by the RRC layer. The Establishment Cause of the received CCCH causes the MAC layer to select a random access preamble from Group C for the following random access procedure. In using preambles from Group C that are set aside for emergency calls, the mobile device <b>140</b> can reduce collisions with the random access procedures of one or more other mobile devices that are being performed for non-emergency purposes, as such procedure would utilize preambles from Group A or Group B.

0064In an exemplary embodiment, the base station <b>120</b> can utilize a PRACH that identifies two groups of random access preambles (Group A and Group B) for emergency services in addition to, or instead of, Group C. That is, the PRACH may identify two groups of preambles, where both preamble groups are used for emergency services, or may identify three groups (A, B and C), where any combination of Groups A, B or C may be used for emergency services. In these examples, the base station <b>120</b> can be configured to identify (using the PRACH) how the preambles of each of the groups are to be utilized in the random access procedure. For example, the base station <b>120</b> can determine that one or more of the Groups of preambles can be used for emergency calls irrespective of whether the connection to the base station <b>120</b> is an initial connection or a connection from a previously associated mobile device <b>140</b>. In an exemplary embodiment, the base station <b>120</b> can be configured to determine that the preambles from Groups A and B can be used for emergency purposes. Therefore, the mobile device <b>140</b> attempting to establish an emergency call can utilize preambles from Groups A and B when performing a random access procedure for emergency services. That is, the mobile device <b>140</b> is not limited to only using preambles from Group A if the connection to the base station <b>120</b> is, for example, an initial connection, or only using preambles from group B if the connection to the base station <b>120</b> is, for example, from a mobile device <b>140</b> having been previously connected. For example, if the mobile device <b>140</b> is attempting to establish an emergency call and the connection to the base station <b>120</b> is an initial connection, the mobile device <b>140</b> can utilize random access preambles from Groups A and B exemplary embodiments where Group C is not defined, or any combination of Groups A, B or C in exemplary embodiments that include third group (i.e., Group C). This can reduce collisions with the random access procedures of one or more other mobile devices that are being performed for non-emergency purposes.

0065In exemplary embodiments, the mobile device <b>140</b> can be configured to utilize a transmission power at or near the maximum transmission power (e.g., at the saturation power) and ramp down the transmission power for subsequent transmissions of the random access preamble associated with the establishment of an emergency call. That is, the mobile device <b>120</b> can be configured to utilize a higher transmission power for the initial transmission of the random access preamble, and ramp down the transmission power by a factor of the power ramping step for each subsequent transmission attempt, if the first attempt is not successful. The transmission power can be determined using the following equation: <br />preambleReceivedTargetPower=preambleInitialReceivedTargetPower+DELTA_PREAMBLE+(preambleTransMax−PREAMBLE_TRANSMISSION_COUNTER)×powerRampingStep<br /> Where the preambleInitialReceivedTargetPower is the initial preamble power, the DELTA_PREAMBLE is the preamble format based offset, the preambleTransMax is the maximum number of preamble transmissions (an integer >0), the PREAMBLE_TRANSMISSION_COUNTER is the number of preambles that have been transmitted (preambleTransMax ≧ an integer ≧1), and the powerRampingStep is a power-ramping factor (an integer >0). For the purposes of this discussion, the preambleTransMax can be referred to as an upper threshold number of RA preambles transmission attempts. In operation, the transmission power is decreased for each subsequent preamble transmission attempt in increments of the powerRampingStep. In exemplary embodiment, the preambleTransMax, DELTA_PREAMBLE, and/or powerRampingStep are determined by the base station <b>120</b> and provided to the mobile device <b>140</b>.

0066For example, for the initial preamble transmission power is equal to preambleInitialReceivedTargetPower+DELTA_PREAMBLE+powerRampingStep×(preambleTransMax−1) as the PREAMBLE_TRANSMISSION_COUNTER initially is set to a value of one. That is, the transmission power for the initial preamble transmission is the initial transmission power value plus the addition of a maximum factor of the powerRampingStep. That is, the transmission power for the initial preamble transmission is equal to, or substantially equal to, the saturation power. For the next preamble transmission attempt, the value of the PREAMBLE_TRANSMISSION_COUNTER is two. Here, the increase in the PREAMBLE_TRANSMISSION_COUNTER reduces the value multiplied by the powerRampingStep; and therefore, reduces the transmission power. For example, if the preambleTransMax equals five (e.g., upper threshold number of RA preamble transmission attempts=5), the transmission power includes a quadrupled (e.g., 5-1) powerRampingStep, while the next preamble transmission attempt would include a lower transmission power as the transmission power would include a tripled (e.g., 5-2) powerRampingStep. As another example, when the preambleTransMax is equal to the PREAMBLE_TRANSMISSION_COUNTER, the transmission power is equal to the preambleInitialReceivedTargetPower+DELTA_PREAMBLE. That is, the transmission power is at or near a minimum transmission power value. For the purposes of this discussion, the minimum transmission power value can be referred to as a low threshold transmission power value (i.e., a low threshold value).

0067In an exemplary embodiment, the mobile device <b>140</b> can be configured to utilize a transmission power at or near the maximum transmission power (e.g., saturation power) for each preamble transmission associated with an emergency call. That is, the mobile device <b>140</b> can be configured to utilize a transmission power at or near the maximum transmission power without ramping down the transmission power for subsequent transmissions of the random access preamble. In this example, the transmission power can be determined using the following equation: <br />preambleReceivedTargetPower=preambleInitialReceivedTargetPower+DELTA_PREAMBLE+(preambleTransMax−1)×powerRampingStep

0068In an exemplary embodiment, the mobile device <b>140</b> can be configured to utilize a transmission power at or near the maximum transmission power (e.g., saturation power) for each preamble transmission associated non-emergency calls in addition to emergency calls. In these examples, the mobile device <b>140</b> can be configured to utilize the ramping down of the transmission power, or the mobile device <b>140</b> can be configured to utilize the maximum or near maximum transmission power for each preamble transmission without the ramping down of the transmission power.

0069<figref idref="DRAWINGS">FIG. 6</figref> illustrates a flowchart <b>600</b> of a transmission power adjustment method for random access preamble transmissions in accordance with an exemplary embodiment of the present disclosure. The method of flowchart <b>600</b> is described with continued reference to one or more of <figref idref="DRAWINGS">FIGS. 1-5</figref>. The steps of the method of flowchart <b>600</b> are not limited to the order described below, and the various steps may be performed in a different order. Further, two or more steps of the method of flowchart <b>600</b> may be performed simultaneously with each other.

0070The method of flowchart <b>600</b> begins at step <b>610</b> and transitions to step <b>620</b>, where the mobile device <b>140</b> is configured to initialize the value of the PREAMBLE_TRANSMISSION_COUNTER and set the value to 1.

0071After step <b>620</b>, the flowchart <b>600</b> transitions to step <b>630</b>, where the transmission power value is determined based on an initial transmission power value and a factor of the power ramping step value.

0072In an exemplary embodiment, the transmission power (preambleReceivedTargetPower) can be determined using the following equation: <br />preambleReceivedTargetPower=preambleInitialReceivedTargetPower+DELTA_PREAMBLE+(preambleTransMax−PREAMBLE_TRANSMISSION_COUNTER)×powerRampingStep

0073Here, the preambleInitialReceivedTargetPower is the initial preamble power, the DELTA_PREAMBLE is the preamble format based offset, the preambleTransMax is the maximum number of preamble transmission (an integer >0) (e.g., the upper threshold number of RA preambles transmission attempts), the PREAMBLE_TRANSMISSION_COUNTER is the number of preambles that have been transmitted (preambleTransMax ≧ an integer ≧1), and the powerRampingStep is a power-ramping factor (an integer >0).

0074After step <b>630</b>, the flowchart <b>600</b> transitions to step <b>640</b>, where the mobile device <b>140</b> is configured to determine if a random access response has been received (e.g., from the base station <b>120</b>) indicating that the random access preamble has been successfully received by the base station <b>120</b>. In an exemplary embodiment, the random access responses is received over a Physical Downlink Shared Channel (PDSCH) resource that is identified with a PDCCH transmission reserved for random access responses.

0075If the random access response has been received by the mobile device (YES at step <b>640</b>), the flowchart <b>600</b> transitions to step <b>670</b> where the flowchart ends. Otherwise (NO at step <b>640</b>), the flowchart <b>600</b> transitions to step <b>650</b>.

0076At step <b>650</b>, the mobile device <b>140</b> is configured to increment the value of the PREAMBLE_TRANSMISSION_COUNTER. In an exemplary embodiment, the value is incremented by 1. However, the value can be incremented by any value as would be understood by those skilled in the relevant arts.

0077After step <b>650</b>, the flowchart <b>600</b> transitions to step <b>660</b>, where the mobile device <b>140</b> is configured to compare the value of the PREAMBLE_TRANSMISSION_COUNTER to the preambleTransMax value. If the PREAMBLE_TRANSMISSION_COUNTER value is less than or equal to the preambleTransMax value (YES at step <b>660</b>), the flowchart <b>600</b> returns to step <b>630</b>. Otherwise (NO at step <b>660</b>), the flowchart transitions to step <b>670</b> where the flowchart ends.

0078In exemplary embodiments, the mobile device <b>140</b> can be configured to perform two or more concurrent random access procedures to establish an emergency call. In these examples, the mobile device <b>140</b> is configured to initiate a second (or more) random access procedure when an acknowledgment associated with prior random access procedure has not been received by the mobile device <b>140</b> within a predetermined amount of time.

0079For example, the mobile device <b>140</b> can be configured to determine whether a Hybrid Automatic repeat request (HARQ) Acknowledgement (ACK) has been received from the base station <b>120</b> by the mobile device <b>140</b>. In this example, the HARQ ACK is used to acknowledge that the base station <b>120</b> has received the identification message (e.g., msg3) from the mobile device <b>120</b>.

0080The mobile device <b>140</b> is configured to determine the amount of time that has passed since the msg3 transmission. In an exemplary embodiment, the mobile device <b>140</b> is configured to determine the number of subframes that have passed since the transmission of the msg3 message. The mobile device <b>140</b> is further configured to compare the elapsed time to a predetermined time threshold. For example, the mobile device <b>140</b> is configured to compare the number of elapsed subframes to a predetermined threshold of subframes. For example, in a random access procedure, if the number of subframes since transmission of the msg3 message exceeds a predetermined threshold of subframes, the mobile device <b>140</b> can be configured to institute another random access procedure. In an exemplary embodiment, the mobile device <b>140</b> is configured to institute a second, concurrent random access procedure if the mobile device <b>140</b> has not received a HARQ ACK for the msg3 transmission within, for example, four subframes. In exemplary embodiments, the second random access procedure is instituted immediately or after applying the randombackoff time as defined in section 5.1.5 of 3GPP TS 36.321 but before the mac-ContentionResolutionTimer expires.

0081In an exemplary embodiment, the mobile device <b>140</b> can be configured to limit the number of random access procedures awaiting HARQ ACK for msg3 transmissions to one. That is, the mobile device <b>140</b> can be configured to prevent more than one random access transmission that is awaiting a HARQ ACK for an msg3 transmission. In this example, the mobile device <b>140</b> can be configured to abort the initial random access procedure if the second random access procedure reaches the stage of transmitting an msg3 message. Here, the initial random access procedure is aborted and the second random access procedure is continued so that an msg3 message is transmitted as a part of the second random access procedure. In this scenario, by the time the second random access procedure is prepared for an msg3 transmission, the initial random access procedure would likely have had multiple opportunities (e.g., 3 attempted msg3 transmissions) to transmit the msg3 message without receiving a HARQ ACK.

0082It should be appreciated that the concurrent random access procedure process is not limited to establishing emergency calls, and in an exemplary embodiment, the mobile device <b>140</b> can be configured to perform two or more concurrent random access procedures for non-emergency calls.

0083<figref idref="DRAWINGS">FIG. 7</figref> illustrates a flowchart <b>700</b> of a random access procedure in accordance with an exemplary embodiment of the present disclosure. The method of flowchart <b>700</b> is described with continued reference to one or more of <figref idref="DRAWINGS">FIGS. 1-6</figref>. The steps of the method of flowchart <b>700</b> are not limited to the order described below, and the various steps may be performed in a different order. Further, two or more steps of the method of flowchart <b>700</b> may be performed simultaneously with each other.

0084The method of flowchart <b>700</b> begins at step <b>705</b> and transitions to step <b>710</b>, where the mobile device <b>140</b> is configured to initiate a first random access procedure. In an exemplary embodiment, the mobile device <b>140</b> is configured to transmit one or more msg3 messages to the base station <b>120</b>.

0085After step <b>710</b>, the method of flowchart <b>700</b> transitions to step <b>715</b>, where the mobile device <b>140</b> can be configured to determine if a Hybrid Automatic repeat request (HARQ) Acknowledgement (ACK) has been received from the base station <b>120</b>. In this example, the HARQ ACK is used to acknowledge that the base station <b>120</b> has received the msg3 transmission from the mobile device <b>120</b> that is associated with the first random access procedure.

0086If the mobile device <b>140</b> has received a HARQ ACK (YES at step <b>715</b>), the flowchart transitions to step <b>750</b> where the flowchart <b>700</b> ends. Otherwise (NO at step <b>715</b>), the flowchart <b>700</b> transitions to step <b>720</b>.

0087At step <b>720</b>, the mobile device <b>140</b> is configured to determine the time elapsed (T_first) since the msg3 transmission of the first random access procedure and to compare the elapsed time (T_first) to a predetermined time threshold (T_threshold). In an exemplary embodiment, the mobile device <b>140</b> is configured to determine the number of subframes that have passed since the msg3 transmission and to compare the number of elapsed subframes to a predetermined subframe threshold.

0088If the elapsed time is greater than the predetermined time threshold (T_first>T_threshold) (YES at step <b>720</b>), the flowchart <b>700</b> transitions to step <b>725</b>. Otherwise (NO at step <b>720</b>), the flowchart returns to step <b>715</b>.

0089At step <b>725</b>, the mobile device <b>140</b> is configured to initiate a second random access procedure. In an exemplary embodiment, the mobile device <b>140</b> is configured to transmit one or more msg3 messages to the base station <b>120</b> for the second random access procedure.

0090After step <b>725</b>, the method of flowchart <b>700</b> transitions to step <b>730</b>, where the mobile device is configured to determine if the second random access procedure reaches the stage of msg3 transmission. If the second random access procedure has reached the msg3 transmission stage (YES at step <b>730</b>), the flowchart <b>700</b> transitions to step <b>735</b>. Otherwise (NO at step <b>730</b>), the flowchart <b>700</b> returns to step <b>730</b> and step <b>730</b> is repeated.

0091At step <b>735</b>, the mobile device <b>140</b> is configured to determine if an acknowledgment has been received for an msg3 transmission of the first random access procedure. For example, the mobile device <b>140</b> can be configured to determine if a HARQ ACK for an msg3 transmission of the first random access procedure has been received.

0092If an acknowledgement for an msg3 transmission of the first random access procedure has been received (YES at step <b>735</b>), the flowchart <b>700</b> transitions to step <b>740</b>, where the mobile device <b>140</b> is configured to abort the second random access procedure. After step <b>740</b>, the flowchart <b>700</b> transitions to step <b>745</b>, where the mobile device <b>140</b> is configured to utilize uplink resources granted to the mobile device <b>140</b> by the base station <b>120</b>. After step <b>745</b>, the flowchart <b>700</b> transitions to step <b>760</b> where the flowchart <b>700</b> ends.

0093If an acknowledgement for an msg3 transmission of the first random access procedure has not been received (NO at step <b>735</b>), the flowchart <b>700</b> transitions to step <b>750</b>, where the mobile device <b>140</b> is configured to abort the first random access procedure. After step <b>750</b>, the flowchart <b>700</b> transitions to step <b>755</b>, where the mobile device <b>140</b> is configured to transmit the msg3 message associated with the second random access procedure. After step <b>755</b>, the flowchart transitions to step <b>760</b> where the flowchart <b>700</b> ends. In an exemplary embodiment; after step <b>755</b>, the flowchart <b>700</b> can return to step <b>715</b>, where the mobile device <b>140</b> can be configured determine if a HARQ ACK has been received from the base station <b>120</b> for the msg3 message associated with the second random access procedure. In this example, the second random access procedure can be reclassified as the “first” random access procedure and another (e.g., “second”) random access procedure can be initiated at step <b>725</b>.

0094In an exemplary embodiment, the monitoring of the msg3 transmission stage at step <b>730</b> and the monitoring for receipt of the HARQ ACK at step <b>735</b> can be performed simultaneously or substantially simultaneously. In this example, if the second random access procedure reaches the stage of msg3 transmission (YES at step <b>730</b>), the flowchart <b>700</b> transitions to step <b>750</b>, where the first random access procedure is aborted and the second random access procedure is continued at step <b>755</b>. Similarly, if the HARQ ACK is received for the first random access procedure (YES at step <b>735</b>), the flowchart transitions to step <b>740</b> where the second random access procedure is aborted and the first random access procedure is continued at step <b>745</b>.

CONCLUSION

0095The aforementioned description of the specific embodiments will so fully reveal the general nature of the disclosure that others can, by applying knowledge within the skill of the art, readily modify and/or adapt for various applications such specific embodiments, without undue experimentation, without departing from the general concept of the present disclosure. Therefore, such adaptations and modifications are intended to be within the meaning and range of equivalents of the disclosed embodiments, based on the teaching and guidance presented herein. It is to be understood that the phraseology or terminology herein is for the purpose of description and not of limitation, such that the terminology or phraseology of the present specification is to be interpreted by the skilled artisan in light of the teachings and guidance.

0096References in the specification to “one embodiment,” “an embodiment,” “an exemplary embodiment,” etc., indicate that the embodiment described may include a particular feature, structure, or characteristic, but every embodiment may not necessarily include the particular feature, structure, or characteristic. Moreover, such phrases are not necessarily referring to the same embodiment. Further, when a particular feature, structure, or characteristic is described in connection with an embodiment, it is submitted that it is within the knowledge of one skilled in the art to affect such feature, structure, or characteristic in connection with other embodiments whether or not explicitly described.

0097The exemplary embodiments described herein are provided for illustrative purposes, and are not limiting. Other exemplary embodiments are possible, and modifications may be made to the exemplary embodiments within the spirit and scope of the disclosure. Therefore, the specification is not meant to limit the disclosure. Rather, the scope of the disclosure is defined only in accordance with the following claims and their equivalents.

0098Embodiments may be implemented in hardware (e.g., circuits), firmware, software, or any combination thereof. Embodiments may also be implemented as instructions stored on a machine-readable medium, which may be read and executed by one or more processors. A machine-readable medium may include any mechanism for storing or transmitting information in a form readable by a machine (e.g., a computing device). For example, a machine-readable medium may include read only memory (ROM); random access memory (RAM); magnetic disk storage media; optical storage media; flash memory devices; electrical, optical, acoustical or other forms of propagated signals (e.g., carrier waves, infrared signals, digital signals, etc.), and others. Further, firmware, software, routines, instructions may be described herein as performing certain actions. However, it should be appreciated that such descriptions are merely for convenience and that such actions in fact results from computing devices, processors, controllers, or other devices executing the firmware, software, routines, instructions, etc. Further, any of the implementation variations may be carried out by a general purpose computer.

0099In embodiments having one or more components that include one or more processors, one or more of the processors can include (and/or be configured to access) one or more internal and/or external memories that store instructions and/or code that, when executed by the processor(s), cause the processor(s) to perform one or more functions and/or operations related to the operation of the corresponding component(s) as described herein and/or as would appreciated by those skilled in the relevant art(s).

0100It is to be appreciated that the Detailed Description section, and not the Summary and Abstract sections, is intended to be used to interpret the claims. The Summary and Abstract sections ma set forth one or more but not all exemplary embodiments of the present disclosure as contemplated by the inventors, and thus, are not intended to limit the present disclosure and the appended claims in any way.

0101The present disclosure has been described above with the aid of functional building blocks illustrating the implementation of specified functions and relationships thereof. The boundaries of these functional building Hocks have been arbitrarily defined herein for the convenience of the description. Alternate boundaries may be defined so long as the specified functions and relationships thereof are appropriately performed.