Enhanced procedures for sending emergency messages to multiple mobile devices

CROSS-REFERENCES TO RELATED APPLICATIONS

This application claims the benefit of U.S. Provisional Patent Application No. 62/736,777, filed on Sep. 26, 2018, the content of which is incorporated by reference in its entirety.

BACKGROUND

Device-to-device (D2D) communication may be referred to as direct communication between two mobile devices without traversing a base station or core network (e.g., a cellular network). There are some situations in which a mobile device user may be outside of coverage areas of cellular communications. For example, a user may be hiking in the woods where there is no cellular coverage. As another example, cellular coverage may be lost in some areas, e.g., after a natural disaster. In such situations, it may be desirable for a mobile device, such as a smart phone, to communicate with other mobile devices in a D2D communication network. For example, in an emergency situation (e.g., an injury during hiking), a user may want to be able to send out emergency signals to people who are near. As another example, in a natural disaster (e.g., a hurricane), it may be advantageous to be able to send out messages to a large group of mobile device users in order to coordinate evacuation or rescue efforts. In some situations, D2D communication may be preferred even if there is cellular coverage. For example, in a sports stadium or in a mall, the cellular signals may be congested. A user may want to turn off cellular communication, and instead communicate with friends using D2D communication. Therefore, there is a need to improved methods of D2D communications.

SUMMARY

According to some embodiments, in a method of device-to-device communication, a user device can initially send an emergency message at a first repeating frequency. When a specified number of acknowledgement (ACK) messages are received, the user device can send the emergency message at a reduced repeating frequency. The repeating frequency may be further reduced, e.g., when more ACK messages are received.

According to some embodiments, a method can provide for efficiently handling the transport block and modulation coding scheme (MCS). When one or more negative acknowledgement (NACK) messages are received, a primary device can resend the transport block at a lower MCS value. This may make the D2D communication more reliable in low coverage conditions.

According to some embodiments, a method of device-to-device (D2D) communication includes, by a first mobile device, sending a request to a second mobile device for transmitting data to the second mobile device; receiving a first modulation coding scheme (MCS) value and a first transport block size from the second mobile device; transmitting, in one or more first frames, the data in a transport block having the first transport block size to the second mobile device using the first MCS value; receiving a specified number of negative acknowledgement (NACK) messages from the second mobile device in response to transmitting the data in the one more first frames; receiving a second MCS value that is lower than the first MCS value from the second mobile device for use in retransmitting the data; and retransmitting the data to the second mobile device in one or more second frames using the second MCS value. In some embodiments, the request includes a buffer status report (BSR). In some embodiments, the second MCS value is determined based on at least one of a reference signal received power (RSRP) value or a signal-to-interference-noise-ratio (SINR) value measured during the one or more first frames. In some embodiments, the specified number of NACK messages may be two. In some embodiments, the method further includes receiving a second NACK message in response to transmitting the data in the one or more second frames; receiving a third MCS value that is lower than the second MCS value from the second mobile device; and retransmitting the data to the second mobile device in at least one third frame using the third MCS value.

These and other embodiments of the disclosure are described in detail below. For example, other embodiments are directed to systems, devices, and computer readable media associated with methods described herein.

A better understanding of the nature and advantages of embodiments of the present disclosure may be gained with reference to the following detailed description and the accompanying drawings.

BRIEF DESCRIPTION OF THE DRAWINGS

<figref idref="DRAWINGS">FIG. 1</figref> illustrates schematically an example device-to-device (D2D) communication group involving a primary device and multiple secondary devices.

<figref idref="DRAWINGS">FIG. 2</figref> illustrates an exemplary frame sequence for broadcasting emergency messages according to some embodiments.

<figref idref="DRAWINGS">FIG. 3</figref> illustrates an exemplary frame sequence for broadcasting emergency messages according to some embodiments.

<figref idref="DRAWINGS">FIG. 4</figref> illustrates an exemplary frame sequence for broadcasting emergency messages according to some embodiments.

<figref idref="DRAWINGS">FIG. 5</figref> is a flowchart illustrating a method of broadcasting emergency messages via D2D communication according to some embodiments.

<figref idref="DRAWINGS">FIG. 6</figref> shows some exemplary plots of power usages as a function of transmit power, for various frequency band groups (e.g., a low frequency band group, a medium frequency band group, and a high frequency band group, respectively, according to some embodiments.

<figref idref="DRAWINGS">FIG. 7</figref> illustrates an exemplary frame sequence for sending synchronization signals in a non-emergency situation according to some embodiments.

<figref idref="DRAWINGS">FIG. 8</figref> illustrates example communication ranges for different transmit powers according to some embodiments.

<figref idref="DRAWINGS">FIG. 9</figref> illustrates another exemplary frame sequence for sending synchronization signals in a non-emergency situation according to some embodiments.

<figref idref="DRAWINGS">FIG. 10</figref> illustrates yet another exemplary frame sequence for sending synchronization signals in a non-emergency situation according to some embodiments.

<figref idref="DRAWINGS">FIG. 11</figref> illustrates an exemplary frame sequence for sending discovery messages according to some embodiments.

<figref idref="DRAWINGS">FIG. 12</figref> illustrates an exemplary frame sequence for sending emergency messages according to some embodiments.

<figref idref="DRAWINGS">FIG. 13</figref> is a flowchart illustrating an example method of D2D communication according to some embodiments.

<figref idref="DRAWINGS">FIG. 14</figref> illustrates different example coverage scenarios of a D2D communication according to some embodiments.

<figref idref="DRAWINGS">FIG. 15</figref> shows a diagram illustrating an example operation of a D2D communication between a first user equipment (UE A) and a second user equipment (UE B) using adaptive MCS according to some embodiments.

<figref idref="DRAWINGS">FIG. 16</figref> is a flowchart illustrating an example method of D2D communication according to some embodiments.

<figref idref="DRAWINGS">FIG. 17</figref> is a block diagram of an example device, which may be a mobile device according to some embodiments.

DETAILED DESCRIPTION

I. Sending Emergency Messages to Many Devices

In an emergency, a user may want to use a mobile device to send emergency messages to other, e.g., a large number of, user devices in the vicinity via D2D communications in order to get help. In normal situations, a user device may keep a “friends list” as a pre-populated list of devices with which the user device may wish to exchange messages. Under routine conditions, the user device may not want to send messages to or receive messages from random people.

However, in emergency situations, the user device may wish to send emergency messages to any or all devices in the vicinity, not just those that are on the friends list. A receiving device may respond by sending an acknowledgement (ACK) message. It is possible that there may be a large number of devices in the vicinity receiving and responding to the emergency messages. Reception of multiple ACK messages with an entire payload (e.g., 32 bits) may lead to usage of a large amount of resources (e.g., draining the battery), and may also lead to collisions as the medium may become congested. The continuing transmission of emergency messages at a high rate can also use a large amount of resources, e.g., battery and the medium.

According to some embodiments, enhanced procedures of sending emergency messages using D2D communications are provided that may alleviate collisions and reduce overhead. The D2D communications may be considered in a primary-secondary relationship. In computer networking, primary-secondary (also referred to as master-slave) is a model for a communication protocol in which one device (referred to as primary or master) controls the communication with one or more other devices (referred to as secondary or slave devices). Once the primary-secondary relationship is established, the direction of control is from the primary device to the secondary device(s).

An alternative radio service (ARS) is one type of radio access technology (RAT) for D2D communication. The D2D communications may include text messages as well as voice messages. The communication range can be as far as several tens of kilometers. An ARS may operate in any unlicensed frequency or frequencies, such as 900 MHz, 2.4 GHz, 5 GHz, or the like. Different countries may have different unlicensed frequency bands.

A. Automatically Reducing Frequency of Sending Emergency Messages

<figref idref="DRAWINGS">FIG. 1</figref> illustrates a device-to-device (D2D) communication group involving a primary device (referred to as user equipment or UE) UE A <b>110</b> and multiple secondary devices <b>120</b><i>a</i>-<b>120</b><i>e</i>. The primary device <b>110</b> may send synchronization signals to the secondary devices <b>120</b><i>a</i>-<b>120</b><i>e </i>to facilitate D2D communication sessions. Global navigation satellite systems (GNSS) signals, such as the global positioning system (GPS) signals, can be an important aspect of D2D communications, as it may be important for the secondary devices <b>120</b> to know the exact location of the primary device <b>110</b> and the exact time when the primary device <b>110</b> broadcast a message. For example, in case of an emergency, the primary device <b>110</b> may broadcast an emergency message to all secondary devices <b>120</b> within a communication range of the primary device <b>110</b> (e.g., within the circle <b>130</b> around the primary device <b>110</b>; note that the secondary device <b>120</b><i>e </i>may be out of the communication range of the primary device <b>110</b> as it may be too far from the primary device <b>110</b>).

A secondary device <b>120</b> receiving the emergency message may need to know the location of the primary device <b>110</b> in order to provide help. The secondary device <b>120</b> may also need to know the time when the emergency message was sent, e.g., in order to determine whether the emergency message is still relevant, to determine whether the transmitting device may have moved, etc. The position information and timing information can be important in other situations. The primary device <b>110</b> may maintain position fixes (e.g., in terms of longitude and latitude) and time through satellite signals. The secondary devices may not have position fixes directly through satellite signals.

The communications between the devices can be implemented using frames. A frame can refer to a digital data transmission unit in computer networking and telecommunication. A frame typically includes frame synchronization features comprising of a sequence of bits or symbols that indicate to the receiver, the beginning and end of the payload data within the stream of symbols or bits it receives.

<figref idref="DRAWINGS">FIG. 2</figref> illustrates an exemplary frame sequence for broadcasting emergency messages according to some embodiments. A frame <b>210</b> may include a number of slots <b>220</b> (e.g., 9 slots). A frame <b>210</b> may be, for example, 342 ms long. A slot <b>220</b> may be, for example, 38 ms long. A beginning portion of a slot (e.g., the initial 5 ms of the slot) may be designated for synchronization signals. In some embodiments, the first slot <b>220</b> in a frame <b>210</b> may be designated for discovery messages and/or emergency messages. The second slot of a frame may be designated for transmitting device control signals. The third slot of a frame may be designated for receiving device control signals.

In emergencies, the first slot <b>220</b><i>a </i>of a frame <b>210</b> may indicate an emergency, e.g., via a flag. In some embodiments, a user device (acting as a primary device, such as UE A <b>110</b> illustrated in <figref idref="DRAWINGS">FIG. 1</figref>) may broadcast emergency messages continuously, e.g., in every frame, as illustrated in <figref idref="DRAWINGS">FIG. 2</figref>, to all nearby secondary devices <b>120</b>. UE A <b>110</b> may receive an acknowledgement (ACK) message <b>230</b> from one of the secondary devices <b>120</b> in a frame (e.g., the frame <b>210</b><i>a</i>). In a conventional procedure, UE A <b>110</b> may continue to broadcast emergency messages frequently, e.g., in every frame, after receiving the ACK message <b>230</b>, as illustrated in <figref idref="DRAWINGS">FIG. 2</figref>.

It is possible that there may be a large number of devices in the vicinity, receiving and responding to the emergency messages. Reception of multiple ACK messages having an entire payload (e.g., 32 bits) may be inefficient, e.g., leading to consumption of a large amount of resources (e.g., draining the battery) and causing collisions. Continuing to transmit emergency messages at a high rate can also use a large amount of resources.

<figref idref="DRAWINGS">FIG. 3</figref> illustrates an exemplary frame sequence for broadcasting emergency messages according to some embodiments. As UE A <b>110</b> receives ACK messages from one or more devices <b>120</b>, UE A <b>110</b> may dynamically and automatically reduce the frequency of broadcasting emergency messages, e.g., based on the number of ACK messages received. For example, as illustrated in <figref idref="DRAWINGS">FIG. 3</figref>, UE A <b>110</b> receives an ACK message <b>320</b> from a first secondary device <b>120</b> (e.g., from the secondary device <b>120</b><i>a</i>) in the frame <b>310</b><i>a</i>. In response to receiving the ACK message <b>320</b>, UE A <b>110</b> may reduce the frequency of broadcasting emergency messages in subsequent frames. For example, UE A <b>110</b> may broadcast emergency messages in every other frame or at an even lower rate (e.g., only in frames <b>310</b><i>c </i>and <b>310</b><i>e</i>, and skipping frames <b>310</b><i>b </i>and <b>310</b><i>d</i>, as illustrated in <figref idref="DRAWINGS">FIG. 3</figref>), instead of in every frame. Since UE A <b>110</b> already received one ACK message, emergency messages may not need to be broadcasted as frequently as help may be already on the way. By broadcasting emergency messages less frequently, the chance of collisions may be reduced. Also, battery power may be better preserved by broadcasting emergency messages less frequently, e.g., extending the period over which emergency messages can be broadcast.

<figref idref="DRAWINGS">FIG. 4</figref> illustrates an exemplary frame sequence for broadcasting emergency messages according to some embodiments. As illustrated, UE A <b>110</b> receives a second ACK message <b>420</b> from a second secondary device <b>120</b> (e.g., from the secondary device <b>120</b><i>b</i>) in the frame <b>410</b><i>a</i>. In response to receiving the second ACK message <b>420</b>, UE A <b>110</b> may further reduce the frequency of broadcasting emergency messages in subsequent frames. For example, UE A <b>110</b> may send emergency messages in only one out of three consecutive frames (e.g., skipping the frames <b>410</b><i>b </i>and <b>410</b><i>c </i>before broadcasting in the frame <b>410</b><i>d</i>, as illustrated in <figref idref="DRAWINGS">FIG. 4</figref>). As more ACK messages are received, UE A <b>110</b> may further reduce the frequency of broadcasting the emergency messages. It should be understood that <figref idref="DRAWINGS">FIGS. 3 and 4</figref> only illustrate some exemplary frame sequences according some embodiments of the enhanced procedures for sending emergency messages. Other frame sequences are also possible according to some other embodiments.

B. Acknowledgement Messages with Reduced Payload Capacity

A full payload capacity of an emergency message may include, for example, 32 bits. Table 1 shows an exemplary payload of a 32-bit emergency reply message according to some embodiments.

<tables id="TABLE-US-00001" num="00001"><table frame="none" colsep="0" rowsep="0"><tgroup align="left" colsep="0" rowsep="0" cols="1"><colspec colname="1" colwidth="217pt" align="center" /><thead><row><entry namest="1" nameend="1" rowsep="1">TABLE 1</entry></row></thead><tbody valign="top"><row><entry namest="1" nameend="1" align="center" rowsep="1" /></row><row><entry>Exemplary payload of a 32-bit emergency reply message.</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="4"><colspec colname="1" colwidth="21pt" align="center" /><colspec colname="2" colwidth="56pt" align="left" /><colspec colname="3" colwidth="21pt" align="center" /><colspec colname="4" colwidth="119pt" align="left" /><tbody valign="top"><row><entry>Field</entry><entry /><entry>Bit</entry><entry /></row><row><entry>#</entry><entry>Field Name</entry><entry>Size</entry><entry>Description</entry></row><row><entry namest="1" nameend="4" align="center" rowsep="1" /></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="4"><colspec colname="1" colwidth="21pt" align="char" char="." /><colspec colname="2" colwidth="56pt" align="left" /><colspec colname="3" colwidth="21pt" align="char" char="." /><colspec colname="4" colwidth="119pt" align="left" /><tbody valign="top"><row><entry>1</entry><entry>MSG(1)/MSG(2)</entry><entry>1</entry><entry>Message type indicator: MSG(1) =</entry></row><row><entry /><entry /><entry /><entry>0; MSG(2) = 1</entry></row><row><entry>2</entry><entry>Emergency</entry><entry>1</entry><entry>Non-emergency = 0; emergency = 1</entry></row><row><entry /><entry>Indicator</entry></row><row><entry>3</entry><entry>Discovery Type</entry><entry>1</entry><entry>0 indicates 1-to-1 (dedicated) discovery</entry></row><row><entry>4</entry><entry>Relay Indication</entry><entry>1</entry><entry>Indicate sender's relaying capability</entry></row><row><entry>5</entry><entry>ARS Version</entry><entry>2</entry><entry>Indicates ARS version</entry></row><row><entry>6</entry><entry>Reserved</entry><entry>1</entry><entry>Reserved for future features</entry></row><row><entry>7</entry><entry>MSG(2) Tx</entry><entry>4</entry><entry>For the MSG(2) payload, these bits are</entry></row><row><entry /><entry>Power</entry><entry /><entry>reutilized to send information about the</entry></row><row><entry /><entry>Indication</entry><entry /><entry>discovery replier (DR) transmission</entry></row><row><entry /><entry /><entry /><entry>power level</entry></row><row><entry>8</entry><entry>Random</entry><entry>3</entry><entry>Random number to ensure the</entry></row><row><entry /><entry>Challenge</entry><entry /><entry>anonymity of the device ID and prevent</entry></row><row><entry /><entry /><entry /><entry>tracking.</entry></row><row><entry>9</entry><entry>Hash of the ID,</entry><entry>18</entry><entry>HDR is the 18 bit output of the keyed</entry></row><row><entry /><entry>random challenge</entry><entry /><entry>hash function MAC(K, mDR), where:</entry></row><row><entry /><entry>and message</entry><entry /><entry>K = MAC(KDI, DR, SD(rDI, rDR, n)) -</entry></row><row><entry /><entry>payload</entry><entry /><entry>Precomputation of key</entry></row><row><entry /><entry /><entry /><entry>KDI, DR - Temporary identifier of the</entry></row><row><entry /><entry /><entry /><entry>pair DI and DR</entry></row><row><entry /><entry /><entry /><entry>rDI - Random challenge present in field</entry></row><row><entry /><entry /><entry /><entry>(7) of the associated MSG(1) concate-</entry></row><row><entry /><entry /><entry /><entry>nated with 6 bits encoding of randomly</entry></row><row><entry /><entry /><entry /><entry>selected logical subcarrier kMSG(1).</entry></row><row><entry /><entry /><entry /><entry>rDR - Random challenge present in</entry></row><row><entry /><entry /><entry /><entry>field (8) concatenated with 6 bits</entry></row><row><entry /><entry /><entry /><entry>encoding of randomly selected logical</entry></row><row><entry /><entry /><entry /><entry>subcarrier kMS(2).</entry></row><row><entry /><entry /><entry /><entry>n - The SFN</entry></row><row><entry /><entry /><entry /><entry>mDR - Concatenation of the payload</entry></row><row><entry /><entry /><entry /><entry>fields (1)//(2)//(3)//(4)//(5)//(6)//(7)</entry></row><row><entry>10</entry><entry>CRC (cyclic</entry><entry>0</entry><entry>The CRC is not transmitted, the hash ID</entry></row><row><entry /><entry>redundancy</entry><entry /><entry>is used instead for integrity protection</entry></row><row><entry /><entry>check)</entry></row><row><entry namest="1" nameend="4" align="center" rowsep="1" /></row></tbody></tgroup></table></tables>

According to some embodiments, in response to receiving an emergency message, a secondary device <b>120</b> may send an ACK message with only one bit, instead of sending an entire payload (e.g., 32 bits) of a regular reply message. This may reduce the probability of collisions and overhead, e.g., when a large number of secondary devices <b>120</b> respond to the emergency message. The remaining payload (e.g., of the full 32-bit message) can be sent in a later frame. The ACK message may serve as a quick “shout” to UE A <b>110</b> that another device is present and received the message. Using the quick “shout” may reduce the chances of multiple devices “shouting” at the same time (hence a “collision”).

In some embodiments, the ACK message may include a Zadoff-Chu (ZC) sequence, e.g., similar to a narrowband Internet of Things (NB-IoT) physical random access channel (NPRACH)). A ZC sequence is a complex-valued mathematical sequence which, when applied to radio signals, gives rise to an electromagnetic signal of constant amplitude. A ZC sequence has the useful property that cyclically shifted versions of the sequence imposed on a signal result in zero correlation with one another at the receiver. In such cases, even when a collision occurs (e.g., when multiple devices <b>120</b> transmit ACK messages at the same time and from the same location), UE A <b>110</b> may still be able to decode the ACK messages.

C. Method of Broadcasting Emergency Messages via D2D Communication

<figref idref="DRAWINGS">FIG. 5</figref> is a flowchart illustrating an example method <b>500</b> of broadcasting emergency messages via D2D communication according to some embodiments. Method <b>500</b> may be performed by a mobile device (e.g., a smart phone) that can communication with other mobile devices.

At <b>502</b>, a first mobile device broadcasts an emergency message in a first plurality of consecutive frames at a first repeating frequency. In some embodiments, broadcasting the emergency message at the first repeating frequency may include broadcasting the emergency message in every frame of the first plurality of consecutive frames, as illustrated in <figref idref="DRAWINGS">FIG. 2</figref>. In some other embodiments, broadcasting the emergency message at the first repeating frequency may include broadcasting the emergency message, e.g., in every other frame of the first plurality of consecutive frames, or in two frames out of every three consecutive frames, or the like. In response to the emergency message, the first mobile device may receive one or more ACK messages from one or more of the plurality of second mobile devices.

At <b>504</b>, the first mobile device receives a first acknowledgement (ACK) message from one of a plurality of second mobile devices.

At <b>506</b>, in response to receiving the first ACK message, the first mobile device broadcasts the emergency message in a second plurality of consecutive frames subsequent to the first plurality of frames at a second repeating frequency that is less than the first repeating frequency. For example, in cases in which broadcasting the emergency message at the first repeating frequency includes broadcasting the emergency message in every frame of the first plurality of consecutive frames, as illustrated in <figref idref="DRAWINGS">FIG. 2</figref>, broadcasting the emergency message at the second repeating frequency may include broadcasting the emergency message, e.g., in every other frame as illustrated in <figref idref="DRAWINGS">FIG. 3</figref>, or in one frame out of every three consecutive frames as illustrated in <figref idref="DRAWINGS">FIG. 4</figref>, etc. Other repeating frequencies are also possible.

It should be appreciated that the specific steps illustrated in <figref idref="DRAWINGS">FIG. 5</figref> provide a particular method of broadcasting emergency messages via D2D communication according to some embodiments. Other sequences of steps may also be performed according to alternative embodiments. For example, alternative embodiments of the present disclosure may perform the steps outlined above in a different order. Moreover, the individual steps illustrated in <figref idref="DRAWINGS">FIG. 5</figref> may include multiple sub-steps that may be performed in various sequences as appropriate to the individual step. Furthermore, additional steps may be added or removed depending on the particular applications. One of ordinary skill in the art would recognize many variations, modifications, and alternatives.

II. Adaptive Transmit Power for Efficient Battery Power Management

In a D2D communication group, such as that illustrated in <figref idref="DRAWINGS">FIG. 1</figref>, a primary device UE A <b>110</b> may repeatedly send synchronization signals (which may include frequency and timing information) and discovery messages at fixed time intervals to multiple secondary devices <b>120</b> at a default transmit power. Although the default transmit power may provide a greater communication range, and thus greater likelihood that another device will detect the signal, higher transmit powers may result in higher battery power usage.

<figref idref="DRAWINGS">FIG. 6</figref> shows some exemplary plots <b>610</b>, <b>620</b>, and <b>630</b> of power usage as a function of transmit power, for various frequency band groups (e.g., a low frequency band group represented by square symbols, a medium frequency band group represented by diamond symbols, and a high frequency band group represented by triangle symbols, respectively). As illustrated in <figref idref="DRAWINGS">FIG. 6</figref>, the power usage may increase exponentially for increasing transmit powers beyond the transmit power level of about 10 dBm for all frequency band groups. Therefore, if the transmit power is kept below about 10 dBm, power usage may be kept relatively low.

According to some embodiments, a battery power management method may loop the transmit power for sending synchronization signals and discovery messages between a default power value and a reduced power value in consecutive frames when a low battery condition is detected in one or more devices in a D2D communication group, thereby conserving the battery power.

A. Non-Emergency Situations

<figref idref="DRAWINGS">FIG. 7</figref> illustrates an exemplary frame sequence for sending synchronization signals in a non-emergency situation according to some embodiments. As illustrated, a frame <b>710</b> may include a plurality of slots <b>720</b> (e.g., 9 slots). A first portion <b>730</b> (e.g., the first bit) of a slot <b>720</b> may be designated for synchronization signals. Different frames can use different power levels for the synchronization signal. In this example, the transmit power may loop through a sequence of high-low-low-low power values for the synchronization signal in consecutive frames. For example, as illustrated in <figref idref="DRAWINGS">FIG. 7</figref>, the synchronization signals may be transmitted at a default power value Tx_defaultfor the frame <b>710</b><i>a</i>, and at reduced power values Tx₁, Tx₂, and Tx₃, for the three subsequent frames <b>710</b><i>b</i>, <b>710</b><i>c</i>, and <b>710</b><i>d</i>, respectively. Tx₁, Tx₂, and Tx₃may have the same value, or many have different values according to various embodiments. The sequence can be repeated in later frames.

For example, the default power value Tx_defaultmay be 25 dBm, and the reduced power value Tx₁, Tx₂, and Tx₃may be 10 dBm. Referring to <figref idref="DRAWINGS">FIG. 6</figref>, based on the power usage curve <b>620</b> as a function of transmit power for a mid-frequency band group, the power usage at a 25 dBm transmit power may be about 2,071 mW, whereas the power usage at a 10 dBm transmit power may be only about 167 mW, which is about one twelfth of 2,071 mW.

Thus, in the exemplary frame sequence illustrated in <figref idref="DRAWINGS">FIG. 7</figref>, assuming that Tx_default=25 dBm and Tx₁=Tx₂=Tx₃=10 dBm, the total power usage for the four frames <b>710</b><i>a</i>-<b>710</b><i>d </i>may be equal to approximately 2,071+167+167+167=2,572 mW, giving rise to an average power usage per frame of about 643 mW. In contrast, if the transmit power is 25 dBm for every frame, the average power usage per frame would be about 2,071 mW, which is about 3.2 times the 643 mW used for the previous sequence. Therefore, a power saving factor of about 3.2 may be realized by looping the transmit power through the sequence of high-low-low-low, as illustrated in <figref idref="DRAWINGS">FIG. 7</figref>.

As radio signals travel through space, signal strengths may be attenuated due to free space path loss. Thus, at certain distance sufficiently far away from a transmitting device, the received power at a receiving device may be below the detection limit of the receiving device. Also, the signal-to-interference-noise-ratio (SINR) may also decrease as the distance from the transmitting device increases, causing communications to be less reliable. Therefore, there may be a limited communication range for a given transmit power. In general, a higher transmit power may have a greater communication range (at the cost of increased power consumption).

<figref idref="DRAWINGS">FIG. 8</figref> illustrates schematically communication ranges for different transmit powers according to some embodiments. At a default transmit power of 25 dBm, the communication range may extend to a first circle <b>820</b> with a first radius <b>840</b> from the primary device <b>810</b>. (It is noted that the coverage pattern may not be circular and different implementations can have different shapes.) At a reduced transmit power of 10 dBm, the communication range may extend to a second circle <b>830</b> with a second radius <b>850</b> that is less than the first radius <b>840</b>.

Thus, in the exemplary frame sequence illustrated in <figref idref="DRAWINGS">FIG. 7</figref>, the communication range may be longer for the frame <b>710</b><i>a</i>, and shorter for the subsequent three frames <b>710</b><i>b</i>-<b>710</b><i>d</i>. Thus, the synchronization signals sent by the primary device <b>810</b> may still reach a longer range, albeit less frequently (e.g., only in one frame out of four consecutive frames), while power usage is significantly reduced (e.g., by a power saving factor of about 3.2). In some embodiments, each frame may be about 342 ms long. Therefore, the fact that synchronization signals may reach the longer range (e.g., extending to the first circle <b>820</b> with the first radius <b>840</b>) only in one frame out of two or more consecutive frames may not be a functional limitation, while the savings in the power usage may be significant. This may be especially advantageous when the battery power of the primary device <b>810</b> is relatively low, as the operating time can be extended.

Other frame sequences may also be used. <figref idref="DRAWINGS">FIG. 9</figref> illustrates another exemplary frame sequence for sending synchronization signals in a non-emergency situation according to some embodiments. In this example, the transmit power alternates between a default power value of 25 dBm and a reduced power value of 10 dBm in consecutive frames <b>910</b><i>a</i>-<b>910</b><i>d </i>(e.g., in a high-low-high-low sequence). The average power usage per frame in this example may be about (2,071+643)/2=1,357 mW. Thus, a power saving factor of about 1.5 may be realized compared to the case where the default transmit power is 25 dBm in every frame.

<figref idref="DRAWINGS">FIG. 10</figref> illustrates yet another exemplary frame sequence for sending synchronization signals in a non-emergency situation according to some embodiments. In this example, the transmit power may loop through a high-low-high-high sequence. Assuming that the default power value is 25 dBm and the reduced power value is 10 dBm, the average power usage per frame in this example may be about (2,071×3+643)/4=1,714 mW. This may provide a power saving factor of about 1.2 compared to the case where the default transmit power is 25 dBm in every frame.

In some embodiments, the duty cycle of the default power value of a frame sequence may be dynamically adjusted based on the battery power level. The duty cycle may be defined as the fraction of frames in a sequence of consecutive frames for which the default power value is used. For example, at or above a first battery threshold, a relatively high duty cycle may be used (e.g., in high-low-high-high sequence illustrated in <figref idref="DRAWINGS">FIG. 10</figref>, where the duty cycle is ¾). When the battery power reaches a lower second battery threshold, the duty cycle may be decreased (e.g., in a high-low-high-low sequence illustrated in <figref idref="DRAWINGS">FIG. 9</figref>, where the duty cycle is ½). When the battery power reaches an even lower third battery threshold, the duty cycle may be still further reduced (e.g., in the high-low-low-low sequence illustrated in <figref idref="DRAWINGS">FIG. 7</figref>, where the duty cycle is ¼).

In some embodiments, the battery power management method may be manually activated by a user, even in situations where the battery power is not at or below an initial low battery threshold. For example, if a user is in a situation where battery charging will not be available for an extended period of time (e.g., 48 hours). The user may want to conserve battery power by manually switching to a power saving mode, for example by manually entering the mode through a settings menu.

The battery power management method may also be used when sending discovery messages in non-emergency situations. <figref idref="DRAWINGS">FIG. 11</figref> illustrates an exemplary frame sequence for sending discovery messages according to some embodiments. Discovery messages <b>1130</b> are usually sent in a first slot <b>1120</b> of a frame <b>1110</b>. In this example, the discovery messages <b>1130</b> may be transmitted at a default power value Tx_defaultfor the frame <b>710</b><i>a</i>, and at reduced power values Tx₁, Tx₂, and Tx₃, for the three subsequent frames <b>1110</b><i>b</i>, <b>1110</b><i>c</i>, and <b>1110</b><i>d</i>, respectively. Tx₁, Tx₂, and Tx₃may have the same value, or may have different values according to various embodiments. The sequence is then repeated. In other implementations, the pattern can be implemented for a different number of frames, such as two, three, five, ten, etc. Similar to the example illustrated in <figref idref="DRAWINGS">FIG. 7</figref>, assuming that the default power value is 25 dBm, and the reduced power value Tx₁, Tx₂, and Tx₃is 10 dBm, a power saving factor of about 3.2 may be realized by looping the transmit power through the sequence of frames, as compared to transmitting the discovery messages at the default power value in every frame. As discussed above in relation to <figref idref="DRAWINGS">FIG. 8</figref>, the communication range may be longer for those frames transmitted at the default power value, and shorter for those frames transmitted at the reduced power value. But the discovery messages may still reach the longer range, albeit less frequently (e.g., only in one frame out of four consecutive frames), while power usage is significantly reduced (e.g., by a power saving factor of about 3.2).

B. Emergency situations

The battery power management method may also be used for sending emergency messages. <figref idref="DRAWINGS">FIG. 12</figref> illustrates an exemplary frame sequence for sending emergency messages according to some embodiments. Emergency messages <b>1230</b> can be sent in a first slot <b>1220</b> of a frame <b>1210</b>. In this example, the emergency messages <b>1230</b> may be transmitted at a default power value Ts_defaultfor the frame <b>1210</b><i>a</i>, and at reduced power values Tx₁, Tx₂, and Tx₃, for the three subsequent frames <b>1210</b><i>b</i>, <b>1210</b><i>c</i>, and <b>1210</b><i>d</i>, respectively. Tx₁, Tx₂, and Tx₃may have the same value, or many have different values according to various embodiments. The sequence is then repeated. Similar to the example illustrated in <figref idref="DRAWINGS">FIG. 11</figref>, assuming that the default power value is 25 dBm, and the reduced power value Tx₁, Tx₂, and Tx₃is 10 dBm, a power saving factor of about 3.2 may be realized by looping the transmit power through the sequence of frames, as compared to transmitting the discovery messages at the default power value in every frame.

As discussed above in relation to <figref idref="DRAWINGS">FIG. 8</figref>, the communication range may be longer for those frames transmitted at the default power value, and shorter for those frames transmitted at the reduced power value. But the emergency messages may still reach the longer range, albeit less frequently (e.g., only in one frame out of four consecutive frames), while power usage is significantly reduced (e.g., by a power saving factor of about 3.2).

C. Method of D2D Communication

<figref idref="DRAWINGS">FIG. 13</figref> is a flowchart illustrating a method of D2D communication according to some embodiments.

At <b>1302</b>, a primary device compares a battery level of the primary mobile device to a threshold. The threshold may be predetermined or preset.

At <b>1304</b>, upon determining that the battery level is below the threshold, the primary device broadcasts advertisement signals or synchronization signals by looping through a sequence of transmit power values for a sequence of consecutive frames. The sequence of transmit power values includes a default power value and at least one reduced power value that is lower than the default power value. For example, the looping of the sequence of transmit power values may be similar to those illustrated in <figref idref="DRAWINGS">FIGS. 9-11</figref>.

It should be appreciated that the specific steps illustrated in <figref idref="DRAWINGS">FIG. 13</figref> provide a particular method of D2D communication according to some embodiments. Other sequences of steps may also be performed according to alternative embodiments. For example, alternative embodiments of the present disclosure may perform the steps outlined above in a different order. Moreover, the individual steps illustrated in <figref idref="DRAWINGS">FIG. 13</figref> may include multiple sub-steps that may be performed in various sequences as appropriate to the individual step. Furthermore, additional steps may be added or removed depending on the particular applications. One of ordinary skill in the art would recognize many variations, modifications, and alternatives.

III. Adaptive Modulation Coding Scheme in Low Coverage

A. Modulation Coding Scheme and Transport Block Size

A vast amount of information is communicated wirelessly using radio communication systems. One of the fundamental aspects of radio communication systems is modulation. Modulation relates to how information is superimposed on a radio carrier, so that the information can be transmitted from one place to another via the radio carrier. Examples of modulation methods include amplitude modulation (AM), frequency modulation (FM), phase modulation (PM), phase shift keying (PSK), and the like, as well as modulation combinations such as quadrature amplitude modulation (QAM), quadrature PSK (QPSK), and the like. In QAM, amplitude and phase information are used to carry the signal. Data is modulated onto in-phase and quadrature elements of a signal: I and Q, and the constellation forms a number of points in the two planes. PSK conveys data by changing the phase of a constant frequency reference signal (the carrier wave). QPSK is a form of PSK in which two bits are modulated at once, selecting one of four possible carrier phase shifts (0, 90, 180, or 270 degrees).

Various modulation schemes and coding rates are defined by standards and may be represented by a modulation coding scheme (MCS) index value. MCS defines the modulation (e.g., QPSK, 16 QAM, 64 QAM, 256 QAM) and coding rate (e.g., ½, ¾, ⅔) to be used in a communication. In general, the higher the MCS, the faster the data rate. On the other hand, decoding may be more difficult as the MCS increases. A transport block is data from an upper layer given to the physical layer to be transmitted in each transmission time interval. The transport block size may be determined based on MCS and the number of physical resource blocks. In general, the higher the MCS, the larger the transport block size.

As discussed above, as radio signals travel through space, signal strengths may be attenuated due to free space path loss. Thus, the SINR may decrease as the distance from the transmitting device increases, causing communications to be less reliable. The SINR may be an indication of a coverage condition.

<figref idref="DRAWINGS">FIG. 14</figref> illustrates different coverage scenarios of a D2D communication. Receiving devices Rx <b>1450</b><i>a </i>located within a first region <b>1422</b> within a first circle <b>1420</b> centered at the location of the transmitting device Tx <b>1410</b> may have relatively good coverage, as the distance from the transmitting device Tx <b>1410</b> is not so large and the path loss may be relatively small. Receiving devices Rx <b>1450</b><i>b </i>located in a second region <b>1432</b> outside the first region <b>1422</b> and within a second circle <b>1430</b> may have moderate coverage, as the distance from the transmitting device Tx <b>1410</b> is increased as compared to the first region <b>1422</b>. Receiving devices Rx <b>1450</b><i>c </i>located in a third region <b>1442</b> outside the second region <b>1432</b> and within a third circle <b>1440</b> may have low coverage, as the distance from the transmitting device Tx <b>1410</b> is further increased. Receiving devices Rx <b>1450</b><i>d </i>located outside the third circle <b>1440</b> may have poor or no coverage, as the path loss may be so great that the received signal level may be below the dynamic range of the receiving devices Rx <b>1450</b><i>d. </i>

In low coverage conditions (e.g., in the third region <b>1442</b> illustrated in <figref idref="DRAWINGS">FIG. 14</figref>), the SINR may be rather low. Even if the signal level is within the dynamic range of a receiving device Rx <b>1450</b>, there may be a higher probability that a transport block is not decoded correctly even after repeated transmissions. In conventional methods, the transmitting device Tx <b>1410</b> may re-transmit the transport block with the same transport block size several more times (e.g., 4 or more times) before dropping it. Therefore, if the transport block is not decoded correctly after repeated transmissions, a receiving device Rx <b>1450</b> may fail to receive the data.

According to some embodiments, an adaptive MCS may be used depending on the coverage conditions. For example, after receiving one or more successive negative acknowledgement (NACK) messages, a lower MCS may be used for subsequent re-transmissions. This may help improve the reliability of the D2D communication and reduce failure rates in low coverage conditions.

B. Operation of D2D Communication

<figref idref="DRAWINGS">FIG. 15</figref> shows a diagram illustrating operation of a D2D communication between a first user equipment (UE A) and a second user equipment (UE B) using adaptive MCS according to some embodiments.

At <b>1510</b>, in a first frame (e.g., frame N), UE A may send an advertisement packet to UE B requesting transmission of data to UE B. UE A may also send a buffer status report (BSR) to UE B. The BSR may provide information about the amount of data available for transmission.

At <b>1520</b>, in response to receiving the advertisement packet from UE A, UE B may send UE A a first MCS and specify a first transport block size.

At <b>1530</b>, UE A may send first data (data <b>1</b>) to UE B, using the first MCS and the first transport block size as provided by UE B.

At <b>1540</b>, in a next frame (e.g., frame N+1), UE B may send a NACK message to UE A indicating that the first data was not correctly decoded.

At <b>1550</b>, UE A may resend the first data to UE B, again using the first MCS and the first transport block size as provided by UE B.

At <b>1560</b>, in a next frame (e.g., frame N+2), UE B may send a second NACK to UE A indicating that the first data is still not correctly decoded. UE B may also send UE A a second MCS that is lower than the first MCS, and specify a second transport block size that is smaller than the first transport block size. For example, the first MCS may have a value of 4 (e.g., corresponding to 16 QAM modulation and ¾ coding rate), and the second MCS may have a value of 2 (e.g., corresponding to QPSK modulation and ¾ coding rate). In some embodiments, the second MCS may be determined based on the current reference signal received quality (RSRQ) and SINR.

At <b>1570</b>, UE A may resend the first data to UE B, using the second MCS and the second transport block size as provided by UE B in this frame.

At <b>1580</b>, in a next frame (e.g., frame N+3), UE B may send a third NACK to UE A, and a third MCS that is lower than the second MCS based on the current RSRQ and SINR. For example, the third MCS may have a value of 1 (e.g., corresponding to QPSK modulation and ½ coding rate). UE B may also send a third transport block size.

At <b>1590</b>, UE A may resend the first data to UE B using the third MCS and the third transport block size as provided by UE B in this frame.

According to some embodiments, this process may be repeated for a number of times until the first data is correctly decoded by UE B. According to some other embodiments, UE A may drop the first data after a pre-determined number of failed attempts.

It should be understood that the exemplary procedure illustrated in <figref idref="DRAWINGS">FIG. 15</figref> is for illustration purposes only. Many variations are possible. For example, UE B may lower the MCS after only one failed decoding attempt, or after three failed decoding attempts.

In some embodiments, in response to receiving one or more NACKs from UE B, UE A may increase the transmit power, so as to increase the RSRP and SINR at UE B.

C. Method of D2D Communication

<figref idref="DRAWINGS">FIG. 16</figref> is a flowchart illustrating a method of D2D communication according to some embodiments.

At <b>1602</b>, a primary mobile device sends a request to a second mobile device for transmitting data to the second mobile device.

At <b>1604</b>, the primary mobile device receives a first modulation coding scheme (MCS) value and a first transport block size from the second mobile device.

At <b>1606</b>, the primary mobile device transmits, in one or more first frames, the data in a transport block having the first transport block size to the second mobile device using the first MCS value.

At <b>1608</b>, the primary mobile device receives a specified number of negative acknowledgement (NACK) messages from the second mobile device in response to transmitting the data in the one more first frames. For example, the specified number of NACK messages may include two NACK messages. In some embodiments, the specified number of NACK messages may include one or more than two NACK messages.

At <b>1610</b>, the primary mobile device receives a second MCS value that is lower than the first MCS value from the second mobile device for use in retransmitting the data.

At <b>1612</b>, the primary mobile device retransmits the data to the second mobile device in one or more second frames using the second MCS value. By lowering the MCS value, the probability that the data will be decoded correctly may be increased, perhaps at the expense of a slower data rate.

It should be appreciated that the specific steps illustrated in <figref idref="DRAWINGS">FIG. 16</figref> provide a particular method of D2D communication according to some embodiments. Other sequences of steps may also be performed according to alternative embodiments. For example, alternative embodiments of the present disclosure may perform the steps outlined above in a different order. Moreover, the individual steps illustrated in <figref idref="DRAWINGS">FIG. 16</figref> may include multiple sub-steps that may be performed in various sequences as appropriate to the individual step. Furthermore, additional steps may be added or removed depending on the particular applications. One of ordinary skill in the art would recognize many variations, modifications, and alternatives.

IV. Example Device

<figref idref="DRAWINGS">FIG. 17</figref> is a block diagram of an example device <b>1700</b>, which may be a mobile device. Device <b>1700</b> generally includes computer-readable medium <b>1702</b>, a processing system <b>1704</b>, an Input/Output (I/O) subsystem <b>1706</b>, wireless circuitry <b>1708</b>, and audio circuitry <b>1710</b> including speaker <b>1750</b> and microphone <b>1752</b>. These components may be coupled by one or more communication buses or signal lines <b>1703</b>. Device <b>1700</b> can be any portable electronic device, including a handheld computer, a tablet computer, a mobile phone, laptop computer, tablet device, media player, personal digital assistant (PDA), a key fob, a car key, an access card, a multi-function device, a mobile phone, a portable gaming device, a car display unit, or the like, including a combination of two or more of these items.

It should be apparent that the architecture shown in <figref idref="DRAWINGS">FIG. 17</figref> is only one example of an architecture for device <b>1700</b>, and that device <b>1700</b> can have more or fewer components than shown, or a different configuration of components. The various components shown in <figref idref="DRAWINGS">FIG. 17</figref> can be implemented in hardware, software, or a combination of both hardware and software, including one or more signal processing and/or application specific integrated circuits.

Wireless circuitry <b>1708</b> is used to send and receive information over a wireless link or network to one or more other devices' conventional circuitry such as an antenna system, an RF transceiver, one or more amplifiers, a tuner, one or more oscillators, a digital signal processor, a CODEC chipset, memory, etc. Wireless circuitry <b>1708</b> can use various protocols, e.g., as described herein. For example, wireless circuitry <b>1708</b> can have one component for one wireless protocol (e.g., Bluetooth®) and a separate component for another wireless protocol (e.g., UWB). Different antennas can be used for the different protocols.

Wireless circuitry <b>1708</b> is coupled to processing system <b>1704</b> via peripherals interface <b>1716</b>. Interface <b>1716</b> can include conventional components for establishing and maintaining communication between peripherals and processing system <b>1704</b>. Voice and data information received by wireless circuitry <b>1708</b> (e.g., in speech recognition or voice command applications) is sent to one or more processors <b>1718</b> via peripherals interface <b>1716</b>. One or more processors <b>1718</b> are configurable to process various data formats for one or more application programs <b>1734</b> stored on medium <b>1702</b>.

Peripherals interface <b>1716</b> couple the input and output peripherals of the device to processor <b>1718</b> and computer-readable medium <b>1702</b>. One or more processors <b>1718</b> communicate with computer-readable medium <b>1702</b> via a controller <b>1720</b>. Computer-readable medium <b>1702</b> can be any device or medium that can store code and/or data for use by one or more processors <b>1718</b>. Medium <b>1702</b> can include a memory hierarchy, including cache, main memory and secondary memory.

Device <b>1700</b> also includes a power system <b>1742</b> for powering the various hardware components. Power system <b>1742</b> can include a power management system, one or more power sources (e.g., battery, alternating current (AC)), a recharging system, a power failure detection circuit, a power converter or inverter, a power status indicator (e.g., a light emitting diode (LED)) and any other components typically associated with the generation, management and distribution of power in mobile devices.

In some embodiments, device <b>1700</b> includes a camera <b>1744</b>. In some embodiments, device <b>1700</b> includes sensors <b>1746</b>. Sensors <b>1746</b> can include accelerometers, compasses, gyrometers, pressure sensors, audio sensors, light sensors, barometers, and the like. Sensors <b>1746</b> can be used to sense location aspects, such as auditory or light signatures of a location.

In some embodiments, device <b>1700</b> can include a GPS receiver, sometimes referred to as a GPS unit <b>1748</b>. A mobile device can use a satellite navigation system, such as the Global Positioning System (GPS), to obtain position information, timing information, altitude, or other navigation information. During operation, the GPS unit can receive signals from GPS satellites orbiting the Earth. The GPS unit analyzes the signals to make a transit time and distance estimation. The GPS unit can determine the current position (current location) of the mobile device. Based on these estimations, the mobile device can determine a location fix, altitude, and/or current speed. A location fix can be geographical coordinates such as latitudinal and longitudinal information.

One or more processors <b>1718</b> run various software components stored in medium <b>1702</b> to perform various functions for device <b>1700</b>. In some embodiments, the software components include an operating system <b>1722</b>, a communication module (or set of instructions) <b>1724</b>, a location module (or set of instructions) <b>1726</b>, an emergency module <b>1728</b> that is used sending and receiving emergency messages as described herein, and other applications (or set of instructions) <b>1734</b>.

Operating system <b>1722</b> can be any suitable operating system, including iOS, Mac OS, Darwin, RTXC, LINUX, UNIX, OS X, WINDOWS, or an embedded operating system such as VxWorks. The operating system can include various procedures, sets of instructions, software components and/or drivers for controlling and managing general system tasks (e.g., memory management, storage device control, power management, etc.) and facilitates communication between various hardware and software components.

Communication module <b>1724</b> facilitates communication with other devices over one or more external ports <b>1736</b> or via wireless circuitry <b>1708</b> and includes various software components for handling data received from wireless circuitry <b>1708</b> and/or external port <b>1736</b>. External port <b>1736</b> (e.g., USB, FireWire, Lightning connector, 60-pin connector, etc.) is adapted for coupling directly to other devices or indirectly over a network (e.g., the Internet, wireless LAN, etc.).

Location/motion module <b>1726</b> can assist in determining the current position (e.g., coordinates or other geographic location identifiers) and motion of device <b>1700</b>. Modern positioning systems include satellite based positioning systems, such as Global Positioning System (GPS), cellular network positioning based on “cell IDs,” and Wi-Fi positioning technology based on a Wi-Fi networks. GPS also relies on the visibility of multiple satellites to determine a position estimate, which may not be visible (or have weak signals) indoors or in “urban canyons.” In some embodiments, location/motion module <b>1726</b> receives data from GPS unit <b>1748</b> and analyzes the signals to determine the current position of the mobile device. In some embodiments, location/motion module <b>1726</b> can determine a current location using Wi-Fi or cellular location technology. For example, the location of the mobile device can be estimated using knowledge of nearby cell sites and/or Wi-Fi access points with knowledge also of their locations. Information identifying the Wi-Fi or cellular transmitter is received at wireless circuitry <b>1708</b> and is passed to location/motion module <b>1726</b>. In some embodiments, the location module receives the one or more transmitter IDs. In some embodiments, a sequence of transmitter IDs can be compared with a reference database (e.g., Cell ID database, Wi-Fi reference database) that maps or correlates the transmitter IDs to position coordinates of corresponding transmitters, and computes estimated position coordinates for device <b>1700</b> based on the position coordinates of the corresponding transmitters. Regardless of the specific location technology used, location/motion module <b>1726</b> receives information from which a location fix can be derived, interprets that information, and returns location information, such as geographic coordinates, latitude/longitude, or other location fix data.

Emergency module <b>1728</b> can send/receive emergency messages to/from other mobile devices as disclosed herein. Emergency module <b>1728</b> can be, e.g., connected to wireless circuitry <b>1708</b>. Emergency module <b>1728</b> can also send/receive acknowledgement (ACK) messages to/from other mobile devices as disclosed herein.

The one or more applications programs <b>1734</b> on the mobile device can include any applications installed on the device <b>1700</b>, including without limitation, a browser, address book, contact list, email, instant messaging, word processing, keyboard emulation, widgets, JAVA-enabled applications, encryption, digital rights management, voice recognition, voice replication, a music player (which plays back recorded music stored in one or more files, such as MP3 or AAC files), etc.

There may be other modules or sets of instructions (not shown), such as a graphics module, a time module, etc. For example, the graphics module can include various conventional software components for rendering, animating and displaying graphical objects (including without limitation text, web pages, icons, digital images, animations and the like) on a display surface. In another example, a timer module can be a software timer. The timer module can also be implemented in hardware. The time module can maintain various timers for any number of events.

The I/O subsystem <b>1706</b> can be coupled to a display system (not shown), which can be a touch-sensitive display. The display system displays visual output to the user in a GUI. The visual output can include text, graphics, video, and any combination thereof. Some or all of the visual output can correspond to user-interface objects. A display can use LED (light emitting diode), LCD (liquid crystal display) technology, or LPD (light emitting polymer display) technology, although other display technologies can be used in other embodiments.

In some embodiments, I/O subsystem <b>1706</b> can include a display and user input devices such as a keyboard, mouse, and/or track pad. In some embodiments, I/O subsystem <b>1706</b> can include a touch-sensitive display. A touch-sensitive display can also accept input from the user based on haptic and/or tactile contact. In some embodiments, a touch-sensitive display forms a touch-sensitive surface that accepts user input. The touch-sensitive display/surface (along with any associated modules and/or sets of instructions in medium <b>1702</b>) detects contact (and any movement or release of the contact) on the touch-sensitive display and converts the detected contact into interaction with user-interface objects, such as one or more soft keys, that are displayed on the touch screen when the contact occurs. In some embodiments, a point of contact between the touch-sensitive display and the user corresponds to one or more digits of the user. The user can make contact with the touch-sensitive display using any suitable object or appendage, such as a stylus, pen, finger, and so forth. A touch-sensitive display surface can detect contact and any movement or release thereof using any suitable touch sensitivity technologies, including capacitive, resistive, infrared, and surface acoustic wave technologies, as well as other proximity sensor arrays or other elements for determining one or more points of contact with the touch-sensitive display.

Further, the I/O subsystem can be coupled to one or more other physical control devices (not shown), such as pushbuttons, keys, switches, rocker buttons, dials, slider switches, sticks, LEDs, etc., for controlling or performing various functions, such as power control, speaker volume control, ring tone loudness, keyboard input, scrolling, hold, menu, screen lock, clearing and ending communications and the like. In some embodiments, in addition to the touch screen, device <b>1700</b> can include a touchpad (not shown) for activating or deactivating particular functions. In some embodiments, the touchpad is a touch-sensitive area of the device that, unlike the touch screen, does not display visual output. The touchpad can be a touch-sensitive surface that is separate from the touch-sensitive display or an extension of the touch-sensitive surface formed by the touch-sensitive display.

In some embodiments, some or all of the operations described herein can be performed using an application executing on the user's device. Circuits, logic modules, processors, and/or other components may be configured to perform various operations described herein. Those skilled in the art will appreciate that, depending on implementation, such configuration can be accomplished through design, setup, interconnection, and/or programming of the particular components and that, again depending on implementation, a configured component might or might not be reconfigurable for a different operation. For example, a programmable processor can be configured by providing suitable executable code; a dedicated logic circuit can be configured by suitably connecting logic gates and other circuit elements; and so on.

Any of the software components or functions described in this application may be implemented as software code to be executed by a processor using any suitable computer language such as, for example, Java, C, C++, C #, Objective-C, Swift, or scripting language such as Perl or Python using, for example, conventional or object-oriented techniques. The software code may be stored as a series of instructions or commands on a computer readable medium for storage and/or transmission. A suitable non-transitory computer readable medium can include random access memory (RAM), a read only memory (ROM), a magnetic medium such as a hard-drive or a floppy disk, or an optical medium, such as a compact disk (CD) or DVD (digital versatile disk), flash memory, and the like. The computer readable medium may be any combination of such storage or transmission devices.

Computer programs incorporating various features of the present disclosure may be encoded on various computer readable storage media; suitable media include magnetic disk or tape, optical storage media, such as compact disk (CD) or DVD (digital versatile disk), flash memory, and the like. Computer readable storage media encoded with the program code may be packaged with a compatible device or provided separately from other devices. In addition, program code may be encoded and transmitted via wired optical, and/or wireless networks conforming to a variety of protocols, including the Internet, thereby allowing distribution, e.g., via Internet download. Any such computer readable medium may reside on or within a single computer product (e.g. a solid state drive, a hard drive, a CD, or an entire computer system), and may be present on or within different computer products within a system or network. A computer system may include a monitor, printer, or other suitable display for providing any of the results mentioned herein to a user.

Although the disclosure has been described with respect to specific embodiments, it will be appreciated that the disclosure is intended to cover all modifications and equivalents within the scope of the following claims.

A recitation of “a”, “an” or “the” is intended to mean “one or more” unless specifically indicated to the contrary. The use of “or” is intended to mean an “inclusive or,” and not an “exclusive or” unless specifically indicated to the contrary. Reference to a “first” element does not necessarily require that a second element be provided. Moreover reference to a “first” or a “second” element does not limit the referenced element to a particular location unless expressly stated.

Ranges may be expressed herein as from “about” one specified value, and/or to “about” another specified value. The term “about” is used herein to mean approximately, in the region of, roughly, or around. When the term “about” is used in conjunction with a numerical range, it modifies that range by extending the boundaries above and below the numerical values set forth. In general, the term “about” is used herein to modify a numerical value above and below the stated value by a variance of 10%. When such a range is expressed, another embodiment includes from the one specific value and/or to the other specified value. Similarly, when values are expressed as approximations, by use of the antecedent “about,” it will be understood that the specified value forms another embodiment. It will be further understood that the endpoints of each of the ranges are included with the range.

All patents, patent applications, publications, and descriptions mentioned herein are incorporated by reference in their entirety for all purposes. None is admitted to be prior art.