Resource allocation control for long term evolution device-to-device discovery

A method, an apparatus, and a computer program product for wireless communication are provided. The apparatus may be a UE. The UE determines whether system information is received for D2D communication. In addition, the UE sets at least one flag based on the system information when the system information is received. Further, the UE determines D2D resources based on the at least one flag.

BACKGROUND

Field

The present disclosure relates generally to communication systems, and more particularly, to resource allocation control for long term evolution device-to-device discovery.

Background

SUMMARY

In an aspect of the disclosure, a method, a computer program product, and an apparatus are provided. The apparatus may be user equipment for wireless communication. The apparatus determines whether system information is received for device-to-device communication. The apparatus sets at least one flag based on the system information. The apparatus determines D2D resources based on the at least one flag.

A first layer of the UE may receive the system information and may set the at least one flag, and a second layer that is higher than the first layer may check the at least one flag and may request the first layer to determine the D2D resources. The first layer may be a radio resource control (RRC) layer, and the second layer may be a proximity-based service (ProSe) protocol layer. The system information may be determined to have been received for D2D communication, and the apparatus may determine whether a set of common D2D resources is indicated in the system information, and may determine a radio resource control (RRC) state of the UE, wherein the at least one flag may be set based on whether the set of the common D2D resources is indicated in the system information, and based on the determined RRC state. The set of common D2D resources may be determined to be indicated in the system information, and the RRC state may be determined to be an RRC idle state, and the apparatus may set the at least one flag by setting a first flag of the at least one flag to indicate for the second layer that a request for an allocation of the D2D resources is unrequired. The apparatus may set the at least one flag by setting a second flag of the at least one flag to indicate that D2D communication is supported. The apparatus may determine from the at least one flag that D2D communication is supported, and that a request for an allocation of the D2D resources is unrequired, and may determine the D2D resources by determining to use the set of common D2D resources indicated in the system information for D2D communication. The set of common D2D resources may be determined to be indicated in the system information, and the RRC state may be determined to be an RRC connected state, and the apparatus may set the at least one flag by setting a first flag of the at least one flag to indicate that a request for an allocation of the D2D resources is required. The apparatus may set the at least one flag by setting a second flag of the at least one flag to indicate that D2D communication is supported. The apparatus may determine from the at least one flag that D2D communication is supported, and that a request for an allocation of the D2D resources is required, and may determine the D2D resources by requesting, at the second layer, the first layer to request an allocation of the D2D resources from a serving base station, and by receiving the allocation of the D2D resources from the serving base station, wherein the determined D2D resources may be the received allocated D2D resources. The apparatus may determine from the at least one flag that D2D communication is supported, and that a request for an allocation of the D2D resources is required, and may determine the D2D resources by requesting, at the second layer, the first layer to request performing the D2D communication with a set of D2D resources from a serving base station, and by receiving a confirmation from the base station that the set of D2D resources is reserved for D2D communication. The set of common D2D resources may be determined to be not indicated in the system information, and the RRC state may be determined to be an RRC idle state, and the apparatus may set the at least one flag by setting a first flag of the at least one flag to indicate for the second layer that a request for an allocation of the D2D resources is required. The apparatus may set the at least one flag by setting a second flag of the at least one flag to indicate that D2D communication is supported. The apparatus may determine from the at least one flag that D2D communication is supported, and that a request for an allocation of the D2D resources is required, and may determine the D2D resources by transitioning from the RRC idle state to an RRC connected state, by requesting, at the second layer, the first layer to request an allocation of the D2D resources from a serving base station, and by receiving the allocation of the D2D resources from the serving base station, wherein the determined D2D resources may be the received allocated D2D resources. The apparatus may control, by the second layer, a third layer that is higher than the first layer to cause the first layer to transition from the RRC idle state to the RRC connected state. The third layer may be a non-access stratum (NAS) layer. The set of common D2D resources may be determined to be not indicated in the system information, and the RRC state may be determined to be an RRC connected state, and the apparatus may set the at least one flag by setting a first flag of the at least one flag to indicate for the second layer that a request for an allocation of the D2D resources is required. The apparatus may set the at least one flag by setting a second flag of the at least one flag to indicate that D2D communication is supported. The apparatus may determine from the at least one flag that D2D communication is supported, and that a request for an allocation of the D2D resources is required, and may determine the D2D resources by requesting, at the second layer, the first layer to request an allocation of the D2D resources from a serving base station, and by receiving the allocation of the D2D resources from the serving base station, wherein the determined D2D resources are the received allocated D2D resources. The apparatus may determine from the at least one flag that D2D communication is supported, and that a request for an allocation of the D2D resources is required, and may determine the D2D resources by requesting, at the second layer, the first layer to request performing the D2D communication with a set of D2D resources from a serving base station, and by receiving a confirmation from the base station that the set of D2D resources is reserved for D2D communication. The system information may be determined to have been received for D2D communication, a set of common D2D resources may be indicated in the system information, and the apparatus may perform D2D communication using the set of common D2D resources, may stop the D2D communication through the set of common D2D resources, and may transition from an RRC idle state to an RRC connected state, wherein the at least one flag may be set upon transitioning from the RRC idle state to the RRC connected state, and wherein the apparatus may set the at least one flag by setting a first flag of the at least one flag to indicate that a request for the allocation of the D2D resources is required. The apparatus may set the at least one flag by setting a second flag of the at least one flag to indicate that D2D communication is supported. The apparatus may determine from the at least one flag that D2D communication is supported, and that a request for an allocation of the D2D resources is required, and may determine the D2D resources by determining, at the second layer, that no D2D resources are available, by requesting, at the second layer, the first layer to request an allocation of the D2D resources from a serving base station, and by receiving the allocation of the D2D resources from the serving base station, wherein the determined D2D resources are the received allocated D2D resources. The system information may be determined to have been received for D2D communication, a set of common D2D resources might not be indicated in the system information, the apparatus may perform D2D communication using an allocated set of D2D resources, may receive a revocation of the use of the allocated set of D2D resources, and may set the at least one flag by setting a first flag of the at least one flag to indicate that a request for the allocation of the D2D resources is required. The apparatus may set the at least one flag by setting a second flag of the at least one flag to indicate that D2D communication is supported. The apparatus may determine from the at least one flag that D2D communication is supported, and that a request for an allocation of the D2D resources is required, and may determine the D2D resources by determining, at the second layer, that no D2D resources are available, by requesting, at the second layer, the first layer to request an allocation of the D2D resources from a serving base station, and by receiving the allocation of the D2D resources from the serving base station, wherein the determined D2D resources are the received allocated D2D resources. The system information may be determined not to have been received for D2D communication, and the apparatus may set the at least one flag by setting a flag of the at least one flag indicating that D2D communication is unsupported, wherein the D2D resources may be determined to be a null set. The apparatus may transmit signals in the D2D resources.

DETAILED DESCRIPTION

The E-UTRAN includes the evolved Node B (eNB)106and other eNBs108, and may include a Multicast Coordination Entity (MCE)128. The eNB106provides user and control planes protocol terminations toward the UE102. The eNB106may be connected to the other eNBs108via a backhaul (e.g., an X2 interface). The MCE128allocates time/frequency radio resources for evolved Multimedia Broadcast Multicast Service (MBMS) (eMBMS), and determines the radio configuration (e.g., a modulation and coding scheme (MCS)) for the eMBMS. The MCE128may be a separate entity or part of the eNB106. The eNB106may also be referred to as a base station, a Node B, an access point, a base transceiver station, a radio base station, a radio transceiver, a transceiver function, a basic service set (BSS), an extended service set (ESS), or some other suitable terminology. The eNB106provides an access point to the EPC110for a UE102. Examples of UEs102include a cellular phone, a smart phone, a session initiation protocol (SIP) phone, a laptop, a personal digital assistant (PDA), a satellite radio, a global positioning system, a multimedia device, a video device, a digital audio player (e.g., MP3 player), a camera, a game console, a tablet, or any other similar functioning device. The UE102may also be referred to by those skilled in the art as a mobile station, a subscriber station, a mobile unit, a subscriber unit, a wireless unit, a remote unit, a mobile device, a wireless device, a wireless communications device, a remote device, a mobile subscriber station, an access terminal, a mobile terminal, a wireless terminal, a remote terminal, a handset, a user agent, a mobile client, a client, or some other suitable terminology.

The eNB106is connected to the EPC110. The EPC110may include a Mobility Management Entity (MME)112, a Home Subscriber Server (HSS)120, other MMEs114, a Serving Gateway116, a Multimedia Broadcast Multicast Service (MBMS) Gateway124, a Broadcast Multicast Service Center (BM-SC)126, and a Packet Data Network (PDN) Gateway118. The MME112is the control node that processes the signaling between the UE102and the EPC110. Generally, the MME112provides bearer and connection management. All user IP packets are transferred through the Serving Gateway116, which itself is connected to the PDN Gateway118. The PDN Gateway118provides UE IP address allocation as well as other functions. The PDN Gateway118and the BM-SC126are connected to the IP Services122. The IP Services122may include the Internet, an intranet, an IP Multimedia Subsystem (IMS), a PS Streaming Service (PSS), and/or other IP services. The BM-SC126may provide functions for MBMS user service provisioning and delivery. The BM-SC126may serve as an entry point for content provider MBMS transmission, may be used to authorize and initiate MBMS Bearer Services within a PLMN, and may be used to schedule and deliver MBMS transmissions. The MBMS Gateway124may be used to distribute MBMS traffic to the eNBs (e.g.,106,108) belonging to a Multicast Broadcast Single Frequency Network (MBSFN) area broadcasting a particular service, and may be responsible for session management (start/stop) and for collecting eMBMS related charging information.

FIG. 2is a diagram illustrating an example of an access network200in an LTE network architecture. In this example, the access network200is divided into a number of cellular regions (cells)202. One or more lower power class eNBs208may have cellular regions210that overlap with one or more of the cells202. The lower power class eNB208may be a femto cell (e.g., home eNB (HeNB)), pico cell, micro cell, or remote radio head (RRH). The macro eNBs204are each assigned to a respective cell202and are configured to provide an access point to the EPC110for all the UEs206in the cells202. There is no centralized controller in this example of an access network200, but a centralized controller may be used in alternative configurations. The eNBs204are responsible for all radio related functions including radio bearer control, admission control, mobility control, scheduling, security, and connectivity to the serving gateway116. An eNB may support one or multiple (e.g., three) cells (also referred to as a sectors). The term “cell” can refer to the smallest coverage area of an eNB and/or an eNB subsystem serving a particular coverage area. Further, the terms “eNB,” “base station,” and “cell” may be used interchangeably herein.

Channel estimates derived by a channel estimator658from a reference signal or feedback transmitted by the eNB610may be used by the TX processor668to select the appropriate coding and modulation schemes, and to facilitate spatial processing. The spatial streams generated by the TX processor668may be provided to different antenna652via separate transmitters654TX. Each transmitter654TX may modulate an RF carrier with a respective spatial stream for transmission.

FIG. 7is a diagram of a device-to-device communications system700. The device-to-device communications system700includes a plurality of wireless devices704,706,708,710. The device-to-device communications system700may overlap with a cellular communications system, such as for example, a wireless wide area network (WWAN). Some of the wireless devices704,706,708,710may communicate together in device-to-device communication using the DL/UL WWAN spectrum, some may communicate with the base station702, and some may do both. For example, as shown inFIG. 7, the wireless devices708,710are in device-to-device communication and the wireless devices704,706are in device-to-device communication. The wireless devices704,706are also communicating with the base station702.

The exemplary methods and apparatuses discussed infra are applicable to any of a variety of wireless device-to-device communications systems, such as for example, a wireless device-to-device communication system based on FlashLinQ, WiMedia, Bluetooth, ZigBee, or Wi-Fi based on the IEEE 802.11 standard. To simplify the discussion, the exemplary methods and apparatus are discussed within the context of LTE. However, one of ordinary skill in the art would understand that the exemplary methods and apparatuses are applicable more generally to a variety of other wireless device-to-device communication systems.

Exemplary embodiments generally provide methods and apparatuses for allowing a UE to communicate with another UE (for example, allowing the UE to announce something over the LTE band, which is received by the other UE).

FIG. 8is a block diagram800depicting various layers that make up a stack of a UE802involved in D2D communication, such as D2D Discovery communication, their functions, and various interfaces therebetween. The various layers of the stack of the UE802include a ProSe (Proximity-based Service) Protocol804, a Non-Access Stratum (NAS) layer806, a RRC layer/sublayer808, and a MAC layer/sublayer810. Various other layers/sublayers may exist in the stack of the UE802of exemplary embodiments. However, the present detailed description will focus on the ProSe Protocol804, the NAS layer806, the RRC layer808, and the MAC layer810, and various interaction channels between different ones of the layers.

Below the ProSe Protocol804is the NAS layer806, which is able to control the state transition of the UE802(e.g., from an “idle state” to a “connected state”). However, the NAS layer806is typically unaware of D2D operation. Furthermore, the NAS layer806is shared and affected by other applications.

Below the NAS layer806is the RRC layer808, which has information with respect to the requirements for D2D radio resources allocation, and which also has information with respect to the current state of the UE802, but is unable to control transition of the UE state. The RRC layer808is able to control the radio resources of the UE802, and is able to communicate with a base station/eNB812of the network. Accordingly, radio resource allocation is only available to, and controlled by, the RRC layer808. Furthermore, radio resource allocation may not be immediately known to the NAS layer806or to the ProSe Protocol804.

Finally, below the RRC layer808is the MAC layer810, which is in charge of transmission scheduling for the UE802. That is, the MAC layer810effectively decides when some message to be transmitted by the UE802goes over the air, which may be scheduled by communicating with the ProSe Protocol804. Also, the RRC layer808can control MAC Radio Resources of the MAC layer810according to system information provided by the network, and according to other events, as will be discussed below.

Embodiments address the fact that information with respect to available D2D resources, and information with respect to a connection state of a generic UE (i.e., connected or idle), are known to only select layers of the stack of said UE. Furthermore, the ability to control, or to transition, said UE from one state to the next (e.g., from the idle state to the connected state) might be possessed by only one or more layers.

For example, a control protocol (e.g., the ProSe Protocol) corresponding to an upper layer of a generic UE is aware of the timing and information constraints corresponding to D2D transmission, but does not have direct access to information corresponding to lower layers (such as the RRC layer).

In exemplary embodiments, under certain circumstances, the ProSe Protocol804may exchange information with the NAS layer806(e.g., via interface822), with the RRC layer808(e.g., via interface821), and with the MAC layer810(e.g., via interface823), while the RRC layer808may communicate with the NAS layer806(e.g., via interface822′). Additionally, the RRC layer808may communicate with the base station/eNB812.

Radio resources allocation for the UE802for D2D communication, such as LTE Direct (LTE-D) Discovery, may be controlled by the network to which the eNB812is connected. Before the UE802can directly communicate with another UE (with which the UE802seeks to engage in D2D Discovery communication), the UE802may obtain permission from the network via the eNB812. Once the UE802receives permission from the network, the UE802may send the code corresponding to its intended communication over the air to the other UE. By using D2D resources that may be referred to as peer discovery resources the UE802is able to be discovered by the other UE, and is thereafter able to directly communicate with the other UE using D2D resources that may be referred to as D2D communication resources. LTE-D Discovery considers three main use cases—1) when system information (e.g., information contained in a System Information Block (SIB)) indicates Type 1 (i.e., common) resources, 2) when the system information indicates only that the network supports LTE-D, and 3) when no system information for D2D is provided. Depending on the use case and a connected/idle state of the UE, the UE may or may not send an RRC message requesting resources (e.g., Type 2 (allocated) resources and/or Type 1 (common) resources). The following are the three main use cases (1, 2, and 3), and their subparts (a, b, and c) for LTE-D Discovery:

Case 1a) When the system information (e.g., the SIB) for D2D communication indicates Type 1 resources (e.g., the system information indicates that a set of D2D resources, such as common peer discovery resources or D2D communication resources, is available via the eNB812from a resources pool), and when the UE802is in the idle state (e.g., an RRC idle state), then the UE802can use the indicated Type 1 resources for D2D Discovery communication, and no RRC message is required. That is, when the UE802is in the idle state, the UE802can make use of information (e.g., resources information) broadcast by the eNB812, and is able to perform radio resource management without additional communication with the eNB812.

Case 1b) When the SIB for D2D communication indicates Type 1 resources, and the UE802is in the connected state (e.g., an RRC connected state), then the UE802sends an RRC message to the eNB812for resources allocation, regardless of whether the UE uses Type 1 or Type 2 resources. That is, when the UE802is in the connected state, the UE802asks the network, via the eNB812, for permission, as well as for information regarding the resources allocation, to allow the UE802to perform the D2D Discovery communication.

Case 1c) When the SIB for D2D communication indicates Type 1 resources, and the UE802transitions from the idle state to the connected state while utilizing the Type 1 resources for peer discovery or for D2D communication, the UE802may end transmission using the current Type 1 resources, and may send an RRC message for resources allocation, and may then resume transmission with the allocated resources indicated by the eNB812.

Case 2a) When the SIB for D2D communication only indicates that the network supports LTE-D (e.g., that the network supports peer discovery, or that discovery is supported), but fails to indicate any Type 1 resources information, and the UE802is in the idle state, the UE802may transition to the connected state, and may then send an RRC message to request the network for resources.

Case 2b) When the SIB for D2D communication indicates that D2D communication and D2D discovery are supported, but fails to indicate any resources information, and the UE802is in the connected state, the UE802will send an RRC message for resources allocation.

Case 2c) When the SIB for D2D communication indicates that D2D communication and D2D discovery are supported, but fails to indicate any resources information, and either the UE802loses its connection with the network or the eNB812revokes the resources granted to the UE802, the UE802may no longer continue to use the resources.

Case 3) When no SIB for D2D is provided (e.g., when the UE802is served by a legacy eNB, and is not connected to a network that supports LTE-D), then the UE802may not perform D2D transmission, and may cease sending code to the MAC layer810. That is, when the eNB812is connected to a network that does not support D2D discovery or D2D communication, the UE802may not engage in D2D communication with the other UE.

Each of the above cases (1a, 1b, 1c, 2a, 2b, 2c, and 3) corresponds to one ofFIGS. 9-13, and will be discussed with respect to exemplary embodiments in further detail below.

The exemplary embodiments provide configurations for the UE802to perform methods of radio resources allocation for LTE D2D communication or LTE D2D discovery, while still operating within the same schemes, or cases, outlined above. That is, the exemplary embodiments provide methods and apparatuses for managing resource allocation to UEs connected to an LTE-D network under various scenarios.

For example, for the purpose of supporting proper D2D resources management, exemplary embodiments allow the RRC layer808to receive a trigger from an upper layer, such as the NAS layer806or the ProSe Protocol804, wherein the trigger causes the RRC layer808to send a “D2D Resource Request” message to the eNB812. This scenario will be discussed with reference to cases 1b, 1c, 2a, and 2b.

Furthermore, exemplary embodiments enable the RRC layer808to indicate or communicate some state change events to the ProSe Protocol804to thereby enable the ProSe Protocol804to decide what actions need to be taken. This scenario will be discussed with reference to cases 2c and 3.

Additionally, exemplary embodiments take into consideration that the sending of an RRC message (e.g., the sending of the D2D Resource Request message by the RRC layer808) is not always accompanied by a state transition of the UE802. In such a case, involving the NAS layer806may not provide any additional benefit, and may reduce efficiency of operation of the UE802. This scenario will be discussed with reference to cases 1b and 2b.

Referring back toFIG. 8, exemplary embodiments provide for efficient UE management of resources for LTE D2D communication by providing an interface, or an interaction channel,821between the ProSe Protocol804and the RRC layer808in the UE802. The interaction channel821enables the RRC layer808to provide information to the ProSe Protocol804, which may handle related state transition of the UE802based on the information (as well as based upon the connection/idle state of the NAS layer806).

In the present embodiment, the information provided by the RRC layer808to the ProSe Protocol804corresponds to: 1) whether the network of the eNB812supports LTE-D (D2D); and 2) whether the RRC layer808will require some action by the other layers of the UE802to enable the RRC layer808to obtain the resources from the eNB812.

For each of the cases described above, the information may be communicated by the RRC layer808to the ProSe Protocol804using one or more flags, thereby enabling the RRC layer808to indicate certain states of the UE802while communicating a relatively small amount of information. In the present embodiment, the RRC layer808communicates the above information to the ProSe Protocol804by setting two flags. For purposes of the present detailed description, these flags may be referred to as a “Trigger Needed” flag, and a “Discovery Supported” flag. These two flags are set by the RRC layer808according to the RRC layer's reading of the SIB.

In referring to the figures, three different configurations of the flags will be discussed. First, a Discovery Supported flag is set (e.g., a value corresponding to the flag is equal to 1), and a Trigger Needed flag is unset (e.g., a value corresponding to the flag is equal to 0) (e.g., case 1a). Second, both of the Discovery Supported flag and the Trigger Needed flag are set (e.g., cases 1b, 1c, 2a, 2b, and 2c). Third, the Discovery Supported flag is unset (the Trigger Needed flag may be set or unset) (e.g., case 3). Although the term “Discovery Supported flag” is used throughout the present specification and in the figures, in other configurations, the “Discovery Supported flag” may be a “D2D Communication Supported flag” that indicates that D2D communication is supported by the network.

Based on the flags and the UE802connection state, the ProSe Protocol804may cause a state transition (e.g., by triggering the NAS layer806), trigger the RRC layer808(e.g., to instruct the RRC layer808to send a request for resources), and/or send a command to the MAC layer810, as will be discussed below.

FIG. 9is a first diagram900illustrating exemplary messaging between UE layers and an eNB. Referring toFIG. 9, the abovementioned case 1a is discussed. In the present case, the network of the eNB812supports LTE, and the UE802is in an idle state. Furthermore, the SIB indicates that Type 1 resources are available, thereby indicating that a common pool of radio resources is available to the UE802to select desired resources therefrom for D2D communication (e.g., peer discovery).

Accordingly, the RRC layer808sets the Discovery Supported flag (e.g., the Discovery Supported flag is set to 1), while the Trigger Needed flag is unset (e.g., the Trigger Needed flag is set to 0). This information can be seen by the ProSe Protocol804in accordance with exemplary embodiments. Furthermore, the flags allow the RRC layer808to communicate useful information to the ProSe Protocol804without communicating information that does not need to be used by the ProSe Protocol804(such as information indicating whether the available resources are Type 1 resources or Type 2 resources).

Furthermore, the MAC Radio Resources for D2D are configured in the MAC layer810by the RRC layer808in accordance with Type 1 resources, according to the information contained in the SIB. Once, the RRC layer808configures the MAC Radio Resources, the ProSe Protocol804communicates with the MAC layer810via an interface, or interaction channel,823(seeFIG. 8) to obtain a transmission opportunity (TxOP) time in accordance with one or more ProSe Application Codes (ProSe App Codes) obtained by the ProSe Protocol804. The interaction channel823enables the ProSe Protocol804to send a query to the MAC layer810so that the ProSe Protocol804can know, and the UE802can coordinate, when to send out the intended LTE-D message corresponding to the ProSe App Code.

In the present case, because no state transition of the UE802is needed for delivery of a message from the UE802, the ProSe Protocol804is able to successfully directly obtain the TxOP from the MAC layer810to enable transmission by the UE802. That is, even though the UE802is in an idle state, because the radio resources of the MAC layer810are configured, and because the resources are indicated as Type 1 resources, no state transition of the UE802is needed for D2D communication or for D2D discovery communication.

Once the ProSe Protocol804contacts the MAC layer810, the MAC layer810decides what information to send back to the ProSe Protocol804regarding transmission time (e.g., what TxOP time to send back), as the MAC layer810needs to assign various times to various intended messages. That is, the ProSe Protocol804communicates with the MAC layer810to determine a future time that the ProSe Protocol804can transmit the ProSe App Code. Accordingly, the MAC layer810sends the chosen TxOP time back to the ProSe Protocol804so that the MAC layer810can relegate a specific time that the ProSe Protocol804can deliver a message (e.g., a ProSe App Code and Message Integrity Checksum (MIC)) in accordance with the TxOP time.

It should be noted that, in the present case, although the ProSe Protocol804obtains a single TxOP time for a single corresponding ProSe App Code, the UE802allows for multiple ProSe App Codes with multiple corresponding respective TxOP times, as will be discussed below.

Upon receiving a valid TxOP time from the MAC layer810, the ProSe Protocol804decides whether to trigger the NAS layer806or the RRC layer808, as will be discussed further below. Because neither trigger is needed in this case, the ProSe Protocol804calculates a Message Integrity Checksum (MIC) (e.g., a security integration check result) for each ProSe Application Code based on the corresponding TxOP time. Thereafter, the ProSe Protocol804sends the ProSe App Code in accordance with the requested and obtained TxOP time communicated by the MAC layer810, and the UE802sends a D2D communication message (e.g., a D2D Discovery communication message) corresponding to the ProSe App Code.

Continuing to refer toFIG. 9, the abovementioned case 1b is discussed. In the present case, the network of the eNB812still supports LTE-D, and the SIB indicates that Type 1 resources are available, but the UE802has been transitioned to a connected state.

In the present case, because the RRC layer808has been transitioned from the idle state (e.g., in case 1a) to the connected state, the MAC Radio Resources are removed from the MAC layer810by the RRC layer808. That is, the RRC layer808sets both of the Discovery Supported flag and the Trigger Needed flag (e.g., the Discovery Supported flag and the Trigger Needed flag are both set to 1), and because the Trigger Needed flag is newly set, the RRC layer808removes D2D Radio Resources from the MAC layer810. Again, the information indicated by the flags can be seen by the ProSe Protocol804.

Unlike the previous case, when the ProSe Protocol804attempts to obtain a TxOP time, in accordance with one or more ProSe App Codes previously obtained by the ProSe Protocol804, via its communications with the MAC layer810, the attempt to obtain the TxOP time fails. Because no discovery radio resources have been configured in the MAC layer810, the MAC layer810uses a “NULL TxOP time” to indicate to the ProSe Protocol804that some action needs to be taken. That is, the MAC layer810sends a “null,” or some other indicator, to the ProSe Protocol804to indicate that no transmission time is available, thereby indicating to the ProSe Protocol804that some action needs to be taken by indicating that no radio resources are available in the discovery period.

Again, the ProSe Protocol804decides whether to trigger the NAS layer806or the RRC layer808. Here, because the Discovery Supported flag and the Trigger Needed flag are both set to 1, and because the UE802has been transitioned to the connected state, no state transition of the UE802is needed. Accordingly, the ProSe Protocol804decides to send a trigger to the RRC layer808.

In greater detail, as a result of failing to obtain a TxOP time, the ProSe Protocol804checks the two abovementioned flags set by the RRC layer808. When the RRC layer808indicates that LTE-D is supported, but action is needed (e.g., the Discovery Supported flag and the Trigger Needed flag are both set to 1), the ProSe Protocol804checks to determine whether the UE802is in the connected state or in the idle state. Because the ProSe Protocol804does not need to know what the SIB indicates as available resources (e.g., Type 1 resources or Type 2 resources), that information does not need to be communicated to the ProSe Protocol804(e.g., from flags of the RRC layer808). That is, following a failed attempt to obtain a TxOP time, the ProSe Protocol804only needs to know that the Trigger Needed flag is set to 1 to know it should determine the state of the UE802(e.g., connected state or idle state). In the present case, because the UE802is in the connected state (e.g., the NAS layer806of the UE802is in the connected state), no state transition is needed, and the ProSe Protocol804tells the RRC layer808to send a request for resources (e.g., a RRC D2D Rsrc Request) to the eNB812.

Upon receiving the trigger (e.g., a trigger for D2D Request) from the ProSe Protocol804, the RRC layer808sends the request (e.g., RRC D2D Resource Request) to the eNB812. Thereafter, the eNB812responds to the RRC layer808responding to the request by sending a response (e.g., RRC D2D Rsrc Resp) back to the RRC layer808. Accordingly, by using the described RRC D2D message exchange, the eNB812is able to better schedule network traffic (e.g., traffic involving the subject UE802and various other UEs using the same eNB812to connect to the network).

Then, the RRC layer808configures the MAC D2D Radio Resources at the MAC layer810in accordance with the information contained in the response received from the eNB812. That is the MAC D2D Radio Resources for D2D are set according to the information obtained as a result of the message exchange between the RRC layer808and the eNB812. Then, the MAC layer810is able to provide the ProSe Protocol804with a TxOP time for D2D transmission.

In a manner similar to the previously described case 1a, also shown inFIG. 9, once the ProSe Protocol804successfully obtains the TxOP time, the ProSe Protocol804calculates a MIC, and thereafter sends a command to the MAC layer810corresponding to the subject ProSe App Code and the calculated MIC, and in accordance with the obtained TxOP time. Thereafter, the MAC layer810initiates a D2D transmission in accordance with the received command.

FIG. 10is a second diagram1000illustrating exemplary messaging between UE layers and an eNB. Referring below toFIG. 10, the abovementioned case 1c is discussed. In the present case, the UE802transitions from an idle state to a connected state. Again, the network of the eNB812supports LTE-D, and the SIB indicates that Type 1 resources are available.

Accordingly, the RRC layer808sets the D2D Radio Resources in the MAC layer810to NULL. That is, the MAC D2D Radio Resources are removed from the MAC layer810by the RRC layer808, so that it can later set the MAC D2D Radio Resources according to the information contained in the previously described RRC message exchange between the RRC layer808and the eNB812. Furthermore, the RRC layer808sets both of the Discovery Supported flag and the Trigger Needed flag, which is information that can be seen by the ProSe Protocol804.

In the present case, the ProSe Protocol804calculates a MIC based upon an obtained ProSe App Code, and sends a command to the MAC layer810in accordance with the ProSe App Code and the calculated MIC, as the ProSe Protocol804is unaware that the RRC layer808has removed the MAC Radio Resources from the MAC layer810. Unlike case 1a, the command sent by the ProSe Protocol804is received in error by the MAC layer810, as the MAC layer810has had its RRC Radio Resources previously removed by the RRC layer808, and has not been reconfigured.

Accordingly, in the present case, the MAC layer810either sends an error notification back to the ProSe Protocol804to inform the ProSe Protocol804that there are no D2D Radio Resources available to the MAC layer810, or alternatively, the ProSe Protocol804simply fails in its attempt to obtain a TxOP time from the MAC layer810(e.g., if a design choice removes the ability for the MAC layer810to send an error notification to the ProSe Protocol804).

Upon receiving the error notification from the MAC layer810(or upon failing to obtain a TxOP time), the ProSe Protocol804determines whether the UE802is in the connected state or the idle state, so that the ProSe Protocol804can decide whether to send a trigger to the RRC layer808(e.g.,FIG. 9, case 1b), or whether to initiate a state transition of the UE802from an idle state to a connected state (e.g., case 2a, described further below with respect toFIG. 11).

In the present case, the ProSe Protocol804recognizes that the UE802is in the idle state by communicating with the NAS layer806. Because the NAS layer806of the UE is in the idle state, the ProSe Protocol804attempts to trigger state transition of the UE802using what is referred to as “legacy message,” or “service request.” By using the legacy message/service request, the ProSe Protocol804communicates with the NAS layer806, and the NAS layer806transitions the UE802to the connected state (ECM_CONNECTED), and indicates to the ProSe Protocol804that the state transition has occurred.

Thereafter, and in a manner similar to case 1b, which is shown inFIG. 9, the ProSe Protocol804sends a trigger for D2D Request to the RRC layer808, thereby instructing the RRC layer808to retrieve resources from the network via the eNB812. Upon receiving the trigger, the RRC layer808sends the request message (e.g., RRC D2D Resource Request message) to the eNB812, and the eNB812responds by sending a response message (e.g., RRC D2D Resource Response message) to the RRC layer808. Then, the RRC layer808configures the MAC D2D Radio Resources at the MAC layer810in accordance with the information contained in the response received from the eNB812, thereby enabling the ProSe Protocol804to successfully obtain a TxOP time from the MAC layer810. Once the ProSe Protocol804successfully obtains the TxOP Time, the ProSe Protocol804calculates a MIC, and thereafter sends a command to the MAC layer810corresponding to the subject ProSe App Code and MIC, and in accordance with the obtained TxOP Time. Thereafter, the MAC layer810initiates a transmission in accordance with the received command.

FIG. 11is a third diagram1100illustrating exemplary messaging between UE layers and an eNB. Referring toFIG. 11, the abovementioned case 2a is discussed. In the present case, the UE802is an idle state. Unlike the previously described scenarios according to exemplary embodiments, the SIB does not indicate that Type 1 resources are available, but instead merely indicates that D2D communication is supported by the network (e.g., the network supports LTE-D).

Accordingly, because the SIB provides no information with respect to the specific type of resources available (e.g., whether Type 1 or Type 2), the MAC D2D Radio Resources are removed from the MAC layer810by the RRC layer808, and the RRC layer808sets both of the Discovery Supported flag (e.g., the D2D Communications Supported flag) and the Trigger Needed flag, which is information that is seen by the ProSe Protocol804. Because both of the flags are set, and because the UE802is in an idle state, the UE802will transition states to become in a connected state.

Again, the ProSe Protocol804calculates a MIC based upon an obtained ProSe App Code, and sends a command to the MAC layer810in accordance with the ProSe App Code and calculated MIC. However, the ProSe Protocol804fails in its attempt to obtain a TxOP time from the MAC layer810, as the MAC layer810has had its D2D Radio Resources previously removed by the RRC layer808. Upon failing to obtain a TxOP time, the ProSe Protocol804communicates with the NAS layer806which indicates to the ProSe Protocol804that the UE802is in an idle state.

Because the UE802is in an idle state, the ProSe Protocol804sends a trigger to the NAS layer806to have the NAS layer806send a service request (SR) (e.g., a service request with type originating calls) to the RRC layer808(e.g., via interaction channel822′ shown inFIG. 8). Then, the NAS layer806sends the service request to the RRC layer808, and the RRC layer808communicates with the MAC layer810, and also communicates with the network via the eNB812in accordance with the procedures corresponding to the service request.

Thereafter, once the UE802is in a connected state, and the NAS layer806receives an indication that the UE802is connected, the NAS layer806communicates to the ProSe Protocol804(e.g., via interaction channel822shown inFIG. 8) that the UE is in a connected state (ECM_CONNECTED). It should be noted that the above interaction between the ProSe Protocol804and the NAS layer806can occur when the UE802loses its connection after being in a connected state (e.g., case 2c inFIG. 11).

Thereafter, and in a manner similar with the scenarios discussed with respect toFIGS. 9 and 10(e.g., cases 1b and 1c), the ProSe Protocol804sends a trigger for D2D Request to the RRC layer808, causing the RRC layer808to send the request to the eNB812, which thereafter responds to request by sending back a response. Then, the RRC layer808configures the MAC D2D Radio Resources at the MAC layer810in accordance with the information contained in the response, and the ProSe Protocol804successfully obtains a TxOP time from the MAC layer810.

In the present case, the ProSe Protocol804polls the MAC layer810on the TxOP time to allow the ProSe Protocol804to understand when it can send the over the air ProSe Code. Once the ProSe Protocol804successfully obtains the TxOP Time, the ProSe Protocol804calculates a MIC, and sends a command to the MAC layer810corresponding to the subject ProSe App Code and MIC, and in accordance with the obtained TxOP Time. Thereafter, the MAC layer810initiates a transmission in accordance with the received command.

FIG. 12is a fourth diagram1200illustrating exemplary messaging between UE layers and an eNB. Referring toFIG. 12, the abovementioned case 2b is discussed. In a manner similar to that shown inFIG. 11(e.g., case 2a), the SIB does not indicate that Type 1 resources are available, but instead merely indicates that D2D communication is supported by the network (e.g., the network supports LTE-D). However, unlike the scenario discussed with respect to case 2a, the UE802is in a connected state. Accordingly, no state transition of the UE802will be needed for the intended D2D communication.

Again, the MAC Radio Resources are removed from the MAC layer810by the RRC layer808, and the RRC layer808sets both of the Discovery Supported flag and the Trigger Needed flag, which is information that is seen by the ProSe Protocol804.

Again, the ProSe Protocol804calculates a MIC based upon an obtained ProSe App Code, sends a command to the MAC layer810in accordance with the ProSe App Code and calculated MIC, and fails in its attempt to obtain a TxOP time from the MAC layer810. Upon failing to obtain a TxOP time, the ProSe Protocol804checks the flags set by the RRC layer808. Because the Trigger Needed flag is set to 1, the ProSe Protocol804determines whether the UE802is in the connected state or the idle state. The ProSe Protocol804determines the state of the UE802by communicating with the NAS layer806, which indicates that the UE802is in a connected state in the present scenario.

Because the UE802is in a connected state, and unlike the scenario described with respect to case 2a, the ProSe Protocol804does not need to send a trigger to the NAS layer806to transition the UE802from an idle state to the connected state. Accordingly, and in a manner similar to the scenarios discussed with respect toFIGS. 9, 10, and 11(cases 1b, 1c, and 2a), the ProSe Protocol804sends a trigger for D2D Resource Request to the RRC layer808, the RRC layer808engages in a message exchange (e.g., an RRC D2D Resource Request message exchange) with the eNB812. Then, the RRC layer808configures the MAC D2D Radio Resources at the MAC layer810according to information obtained from the eNB812via the D2D Resource Request message exchange, and the ProSe Protocol804successfully obtains a TxOP time from the MAC layer810. Then, the ProSe Protocol804sends a command to the MAC layer810corresponding to the subject ProSe App Code and the calculated MIC, and in accordance with the obtained TxOP Time, thereby enabling the MAC layer810to initiate a transmission in accordance with the received command.

FIG. 13is a fifth diagram1300illustrating exemplary messaging between UE layers and an eNB. Referring toFIGS. 11 and 13, the abovementioned case 2c is discussed. Unlike the previously described embodiments, the system information/SIB indicates that the D2D Resources are allocated by the eNB812. That is, instead of having a Type 1 Resources pool for the UE802to choose its resources, Type 2 Resources are assigned, or allocated, to the UE802as determined by the network to which the eNB812is connected. That is, Type 2 indicates that the network tells the UE802specifically which resources to use, and provides the UE802with dedicated resources, as opposed to the UE802selecting the resources from a pool of resources (e.g., Type 1). Furthermore, the UE802is in a connected state.

Accordingly, and in the present case, the ProSe Protocol804successfully obtains a TxOP time from the MAC layer810, and the ProSe Protocol804sends a command to the MAC layer810corresponding to the subject ProSe App Code and the calculated MIC, and in accordance with the obtained TxOP Time, thereby enabling the MAC layer810to initiate a transmission in accordance with the received command. However, in the present scenario, before the MAC layer810successfully completes the intended D2D communication, the eNB812sends a RRC D2D Resources Revoked message to the RRC layer808, as shown inFIG. 13(although the following description will also apply when the UE802somehow otherwise loses connection, as shown inFIG. 11).

Thereafter, the RRC layer808indicates to the ProSe Protocol804that both of the Discovery Supported flag and the Trigger Needed flag are set, and the RRC layer808removes the MAC D2D Radio Resources from the MAC layer810. Accordingly, when the ProSe Protocol804sends a command to the MAC layer810in accordance with the ProSe App Code and calculated MIC, the ProSe Protocol804fails in its attempt to obtain a TxOP time from the MAC layer810. Thereafter, the ProSe Protocol804communicates with the NAS layer806, which indicates that the UE802is still in a connected state, and therefore no state transition is needed, and the ProSe Protocol804does not need to send a trigger for a service request SR to the NAS layer806(as was the case in the scenario described with respect to case 2a).

Again, and in a manner similar to the scenarios discussed with respect toFIGS. 9, 10, 11, and 12(cases 1b, 1c, 2a, and 2b), because the NAS layer806indicates that the UE802is in a connected state, the ProSe Protocol804sends a trigger for D2D Request to the RRC layer808, the RRC layer808engages in an RRC D2D Resource message exchange with the eNB812, and configures the MAC D2D Radio Resources at the MAC layer810according to the D2D Resource message exchange. Then, the ProSe Protocol804successfully obtains a TxOP time from the MAC layer810, sends a command to the MAC layer810corresponding to the subject ProSe App Code and the calculated MIC in accordance with the obtained TxOP Time, thereby enabling the MAC layer810to initiate a transmission in accordance with the received command.

According to other cases that may be experienced by exemplary embodiments, when an error occurs either in the RRC layer's808receiving a response to its RRC D2D Resource Request from the eNB812, or in the RRC layer's808configuring of the MAC D2D Radio Resources, the ProSe Protocol804will resend the trigger for D2D Request to the RRC layer808after a timeout has occurred. That is, after a set amount of time has passed following the initial sending of the trigger to the RRC layer808from the ProSe Protocol804, when the ProSe Protocol804receives no communication from the MAC layer810, the ProSe Protocol804resends the D2D Request to the RRC layer808to reinitiate a portion of the process described above.

Finally, in an alternative case (e.g., case 3, not shown), the RRC layer808may indicate to the ProSe Protocol804that the Discovery Supported flag is not set (e.g., that the network connected to the serving base station/eNB812does not support peer discovery). In such a scenario, the ProSe Protocol804should not attempt D2D operations.

Also considered as potential cases by exemplary embodiments are situations wherein the ProSe Protocol804seeks to deliver multiple ProSe App Codes. The ProSe Protocol804may have multiple ProSe Application Codes to be announced over the air. When the ProSe Protocol804has multiple ProSe Application Codes to send, the ProSe Protocol804requests and obtains multiple TxOP times from the MAC layer810via the interaction channel823. Because the resources for the D2D transmission are distributed in both frequency and time domains, it is possible that the resources for the multiple TxOP opportunities correspond to different absolute time values. For example, when the ProSe Protocol804requests two transmission opportunities, the MAC layer810may return a time t and a time t+1 second. These times may be based on selection from Type 1 resources pool, or based on an allocation of resources as determined by the eNB812.

Accordingly, in the present scenario, the ProSe Protocol804calculates an individual MIC for each of the ProSe Application Codes based on the different times. For example, a first MIC for ProSe App Code 1 is calculated with the time t, and a second MIC for ProSe App Code 2 is calculated with the time t+1.

Accordingly, to ensure that the transmission times t and t+1 for the different messages match their respective MIC, which thereby ensures that a receiving UE (to which the UE802seeks to deliver the messages) can correctly validate the messages, when the ProSe Protocol804sends the ProSe App Code and MIC to the MAC layer810for transmission, the ProSe Protocol804informs the MAC layer810which ProSe App Code should be transmitted at which time. The exemplary embodiments provide two approaches to indicate the transmission opportunity between the MAC layer810and the ProSe Protocol804. That is, below are provided two possible approaches to indicate the transmission opportunity TxOP times between the MAC layer810and the ProSe Protocol804.

In the first approach, a system of indexing uses separate index numbers assigned to respective TxOP times to distinguish the different TxOP times. For example, when the ProSe Protocol804requests multiple TxOP, the MAC layer810will index each of these TxOP times with an index number.

When the ProSe Protocol804sends down (e.g., through the lower layers) one of the ProSe App Codes and the corresponding MIC towards MAC layer810, the ProSe Protocol804may indicate the index number corresponding to the particular TxOP time used for the calculation of the particular MIC. In the present embodiment, the MAC layer810provides the TxOP times in a sequence, and the ProSe Protocol804may send the various ProSe Protocol Codes and corresponding MICs according to the same sequence as the time used for the respective MIC calculations. When the MAC layer810responds to the ProSe Protocol804, the MAC layer810includes a corresponding time value for each of the TxOP times provided, even though some of the time values may be identical.

In a second, alternative approach, the ProSe Protocol804sends the ProSe App Code and MIC together with the TxOP time used for the MIC calculation when the ProSe Protocol804transmits the ProSe App Code. Accordingly, the ProSe Protocol804may send a TxOP request to request multiple TxOP opportunities, one for each of the ProSe App Codes. Then, the ProSe Protocol804indicates in the TxOP request sent to the MAC layer810the number of ProSe App Codes to be transmitted. The MAC layer810may respond with a list of the TxOP times in accordance with the request received from the ProSe Protocol804. The MAC layer810of the present embodiment may respond with an individual index number for each TxOP time, or may send in a sequence that implies the index for all of the TxOP times, in which case the MAC layer810remembers the mapping between the various index numbers and their corresponding TxOP time. However, the ProSe Protocol804may include the TxOP time when sending the command for ProSe App Code transmission, thereby obviating any need for the MAC layer810to remember index number mapping.

Furthermore, in an alternative operation, the ProSe Protocol804may use multiple requests when it has multiple codes to send, instead of sending a single TxOP request indicating multiple TxOP times are requested. In such an alternative operation, the ProSe Protocol804would indicate in the request whether it is for the TxOP a new code, or whether the ProSe Protocol804is requesting for a new TxOP for an existing/previous ProSe Application Code. For example, ProSe Protocol804can index the ProSe App Code with an index number, and include it in the request. This way, the MAC layer knows whether the request is for a new ProSe App Code, although the MAC layer may to remember the mapping of the index and the corresponding TxOP resources allocated to it.

The RRC layer808may encounter a situation where the available radio resources have changed. For example, in the case of Type 2 resources allocation (e.g.,FIG. 13, case 2c), the eNB812may decide to add or reduce the resources allocated to the UE802based on the eNB's812load, or based on the number of UEs requesting for the D2D transmission. When the available radio resources have changed, the RRC layer808may inform the ProSe Protocol804to take corresponding action.

For example, the RRC layer808may send an indication (that the available radio resources have changed) toward the ProSe Protocol804with a system level indicator (e.g., a “Resource Updated” indicator). This will trigger the ProSe Protocol804to either request more TxOP times from the MAC layer810, or send the trigger to RRC layer808for resources allocation, along with another indication of the extent of the resources are required. The RRC layer808can respond with the actual resources allocated by the network.

In an alternative embodiment, when the RRC layer808encounters a situation where the available radio resources have changed, the RRC layer808may just configure the MAC layer810with the updated resources. Accordingly, when the ProSe Protocol804requests the TxOP time at the next opportunity by communicating with the MAC layer810, the ProSe Protocol will notice the change in network resources (e.g., the ProSe Protocol may see only two TxOP values although it requested three from the MAC layer810). In this case, the ProSe Protocol804would decide the corresponding operation (e.g. suspending the transmission of one or more of the ProSe App Codes according to a set of priorities, or alternate the transmission of the three codes with the two possible TxOP opportunities).

It should be noted that, although the above description of the described cases focused on the UE802as a transmitter UE802(e.g., an Announcing UE in the LTE-D), the above description can be also applicable to a receiving UE (e.g., the other UE, or a Monitoring UE). In this case, the Monitoring UE is in a connected state, or when the network indicates no resources in the SIB, the RRC layer808may set the Trigger Needed flag (e.g., set the value to 1). When the ProSe Protocol804decides that it desires to receive the ProSe App Code, it will trigger the RRC layer808to send the RRC D2D Resource Request message towards the eNB812. When the eNB812responds with the corresponding confirmation, the RRC layer808may set the MAC layer810accordingly to receive at the D2D resources.

In the present case, the RRC D2D Resource Request is no longer for D2D transmission resources, but is instead used to indicate to eNB812that the UE would perform D2D operation at the receiving resources, such that the eNB812should avoid scheduling any normal LTE communication over those resources, thereby potentially avoiding adverse impact to the UE's other applications. Therefore, the D2D Resource Response message sent to the RRC layer808back from the eNB812does not have to include the resources information, but may instead merely include a confirmation.

In another alternative case, the Announcing UE can be a Monitoring UE as well, wherein the same operation applies. In such a case, the RRC D2D Resource Request message sent to the eNB812would indicate whether the message corresponds for transmission resources, for receiving scheduling assistance, or for both. The RRC D2D Resource Response message sent back from the eNB812would include transmission resources when the message corresponds to transmission resources, or to both transmission resources and receiving scheduling assistance.

In another alternative case, the Monitoring UE may indicate to the RRC layer808that it only desires to receive for a specific public land mobile network (PLMN) or a specific country code. In that case, the RRC layer808may translate that request, and may indicate that desire in the corresponding RRC D2D Resources Request. In the RRC D2D Resources Response, the eNB812may instruct the UE802to operate in a certain manner to carry out the monitoring action (e.g., may instruct the UE802to leave gap for the re-tuning of frequency at certain time).

FIG. 14is a flow chart1400of a method of wireless communication. The method may be performed by a UE (e.g., the UE802).

If the system information indicates that the network does support peer discovery, or does support D2D communication, then the RRC layer sets the flag (e.g., the Discovery Supported flag, or the D2D Communication Supported flag), such that a value corresponding thereto is 1, at step1410. At step1412, the RRC layer determines whether the system information indicates Type 1 Resources, and at step1414, the RRC layer determines whether the UE is in an idle state. If the RRC layer determines at steps1412and1414either that the system information fails to indicate Type 1 resources, or that the UE is not in the idle state (e.g., the UE is in a connected state), then the RRC layer sets another flag (e.g., a first flag, or the Trigger Needed flag) at step1416, and then removes the D2D Radio Resources of a MAC layer (e.g., the MAC layer810) at step1418.

However, if RRC layer determines that the system information does indicate Type 1 resources, and that the UE is in the idle state, the RRC layer will unset the other flag (e.g., set the Trigger Needed flag to 0) at step1420, and will configure the D2D Radio Resources of the MAC layer at step1422.

After the RRC layer either configures the D2D Radio Resources of the MAC layer at step1422, or removes the D2D Radio Resources of the MAC layer at step1418, the ProSe Protocol will attempt to obtain a TxOP time from the MAC layer at step1424. It should be noted that multiple ProSe Application Codes may be obtained within the framework ofFIG. 14, in which case, multiple corresponding MICs will be calculated, and multiple TxOP times may be obtained from the MAC layer, as discussed above.

If the ProSe Protocol's attempt is successful, at step1426, the ProSe Protocol calculates a Message Integrity Checksum (MIC) for the ProSe Application Code, which was obtained at step1402, and sends the MIC and the ProSe Application Code to the MAC layer.

However, if the ProSe Protocol's attempt to obtain the TxOP time from the MAC layer at step1424is unsuccessful, then at step1428, the ProSe Protocol checks the flags set by the RRC layer (e.g., to verify that the Trigger Needed flag is set and/or to verify the Discovery Supported flag is set).

If, after sending the MIC and the ProSe Application Code to the MAC layer at step1426, an error notification is received by the ProSe Protocol from the MAC layer at step1430, or after verifying that the Trigger Needed flag is set at1428, the ProSe Protocol checks with the NAS layer to determine whether the UE is in the connected state at step1432.

If the UE is determined to not be in a connected state at step1432, then at step1434, the ProSe Protocol sends a service request to trigger the NAS layer to switch to a connected state. Then, at step1436, the UE is transitioned to a connected state. Then at step1438, the NAS layer indicates to the ProSe Protocol that the RRC is in a connected state.

After step1438, or alternatively, if the UE is determined to be in a connected state at step1432, the ProSe Protocol layer instructs the RRC layer to send a request for resources to a serving base station (e.g., the eNB812) at step1440. At step1442, the RRC layer requests allocation of resources from the serving base station. At step1444, the serving base station sends a response to the RRC layer allocating D2D resources, such as peer discovery resources or D2D communication resources. Thereafter, the RRC layer returns to step1422, and configures the Radio Resources of the MAC layer.

However, if no error notification is received by the ProSe Protocol from the MAC layer at step1430, if the radio resources are not revoked by the eNB at step1446, and if the D2D communication has not been terminated at step1448, then the UE may return to step1402to obtain additional ProSe Application Codes for further transmissions.

Alternatively, if the resources are revoked, the RRC layer returns to step1416to set the Trigger Needed flag. If the D2D communication is terminated at step1448, then the process ends.

FIG. 15is a diagram1500illustrating a first method of wireless communication. The method may be performed by a UE, such as the UE802. At1502, the UE determines whether system information is received for D2D communication. A first layer of the UE may receive the system information and set the at least one flag, and a second layer that is higher than the first layer may check the at least one flag and request the first layer to determine the D2D resources (e.g., peer discovery resources).

At1504, in one configuration, when the system information is determined to have been received for D2D communication, the UE may determine whether a set of D2D resources (e.g., common peer discovery resources) is indicated in the system information. At1506, the UE may determine a radio resource control (RRC) state of the UE.

At1508, in one configuration, when the system information is determined to have been received for D2D communication, and when a set of D2D resources, such as a set of common peer discovery resources, is indicated in the system information, the UE may perform D2D communication, such as D2D peer discovery communication, using the set of D2D resources. At1510the UE may stop the D2D communication through the set of D2D resources. At1512, the UE may transition from an RRC idle state to an RRC connected state.

At1514, in one configuration, when the system information is determined to have been received for D2D communication, and when a set of D2D resources, such as a set of common peer discovery resources, is not indicated in the system information, the UE may perform D2D communication, such as D2D peer discovery communication, using an allocated set of resources. At1516, the UE may receive a revocation of the use of the allocated set of resources.

At1518, the UE sets at least one flag based on the system information when the system information is received. The at least one flag may be set based on whether the set of the D2D resources is indicated in the system information, and based on the determined RRC state. When the set of D2D resources is determined to be indicated in the system information, and when the RRC state is determined to be an RRC idle state, and the setting the at least one flag may include setting a first flag of the at least one flag to indicate for the second layer that a request for an allocation of the D2D resources is unrequired. When the set of D2D resources is determined to be indicated in the system information, and when the RRC state is determined to be an RRC connected state, the setting the at least one flag may include setting a first flag of the at least one flag to indicate that a request for an allocation of the D2D is required. When the set of D2D resources is determined to be not indicated in the system information, and when the RRC state is determined to be an RRC idle state, the setting the at least one flag may include setting a first flag of the at least one flag to indicate for the second layer that a request for an allocation of the D2D resources is required. When the set of D2D resources is determined to be not indicated in the system information, and when the RRC state is determined to be an RRC connected state, the setting the at least one flag may include setting a first flag of the at least one flag to indicate for the second layer that a request for an allocation of the D2D resources is required. The at least one flag may be set upon transitioning from the RRC idle state to the RRC connected state. The setting the at least one flag may include setting a first flag of the at least one flag to indicate that a request for the allocation of the D2D resources is required. When the system information is determined not to have been received for D2D communication, and when setting the at least one flag includes setting a flag of the at least one flag indicating that D2D communication is unsupported, the D2D resources may be determined to be a null set. At1520, the UE determines D2D resources based on the at least one flag.

In one configuration, the first layer is an RRC layer, and the second layer is a ProSe protocol layer. For cases 1a, 1b, 2a, 2b, in one configuration, the system information is determined to have been received for D2D communication (1502), and the UE determines whether a set of D2D resources, such as a set of common peer discovery resources, is indicated in the system information (1504), and determines an RRC state of the UE (1506). In such a configuration, the at least one flag is set based on whether the set of the D2D resources is indicated in the system information, and based on the determined RRC state (1518).

In one configuration, for case 1a, the set of D2D resources (e.g., common peer discovery resources) is determined to be indicated in the system information (1504), and the RRC state is determined to be an RRC idle state (1506). In addition, the first layer sets the at least one flag by setting a first flag of the at least one flag to indicate for the second layer that a request for an allocation of the D2D resources is unrequired (1518). In one configuration, the first layer sets the at least one flag by setting a second flag of the at least one flag to indicate that D2D communication is supported (1518). In one configuration, the UE determines from the at least one flag that D2D communication is supported, and that a request for an allocation of the D2D resources is unrequired. In such a configuration, the UE determines the D2D resources by determining to use the set of D2D resources indicated in the system information for D2D communication (1520).

In one configuration, for case 1b, the set of D2D resources (e.g., common peer discovery resources) is determined to be indicated in the system information (1504), and the RRC state is determined to be an RRC connected state (1506). In such a configuration, the first layer sets the at least one flag by setting a first flag of the at least one flag to indicate that a request for an allocation of the D2D resources is required (1518). In one configuration, the first layer sets the at least one flag by setting a second flag of the at least one flag to indicate that D2D communication is supported (1518). In one configuration, the UE determines from the at least one flag that D2D communication is supported, and that a request for an allocation of the D2D resources is required. In such a configuration, the UE determines the D2D resources by requesting, at the second layer, the first layer to request an allocation of the D2D resources from a serving base station; and by receiving the allocation of the D2D2 resources from the serving base station (1520). In such a configuration, the determined D2D resources are the received allocated D2D2 resources. In one configuration, the UE determines from the at least one flag that D2D communication is supported, and that a request for an allocation of the D2D resources is required. In such a configuration, the UE determines the D2D resources by requesting, at the second layer, the first layer to request performing D2D communication with a set of D2D resources from a serving base station; and by receiving a confirmation from the base station that the set of D2D resources is reserved for D2D communication (e.g., peer discovery) (1520).

In one configuration, in case 2a, the set of D2D resources (e.g., common peer discovery resources) is determined to be not indicated in the system information (1504), and the RRC state is determined to be an RRC idle state (1506). In such a configuration, the first layer sets the at least one flag by setting a first flag of the at least one flag to indicate for the second layer that a request for an allocation of the D2D resources is required (1518). In one configuration, the first layer sets the at least one flag by setting a second flag of the at least one flag to indicate that D2D communication is supported (1518). In one configuration, the UE determines from the at least one flag that D2D communication is supported, and that a request for an allocation of the D2D resources is required. In such a configuration, the UE determines the D2D resources by transitioning from the RRC idle state to an RRC connected state by requesting, at the second layer, the first layer to request an allocation of the D2D resources from a serving base station, and by receiving the allocation of the D2D resources from the serving base station (1520). In such a configuration, the determined D2D resources are the received allocated D2D resources. In one configuration, the UE controls, by the second layer, a third layer that is higher than the first layer to cause the first layer to transition from the RRC idle state to the RRC connected state. In one configuration, the third layer is a NAS layer.

In one configuration, in case 2b, the set of D2D resources (e.g., common peer discovery resources) is determined to be not indicated in the system information (1504), and the RRC state is determined to be an RRC connected state (1506). In such a configuration, the first layer sets the at least one flag by setting a first flag of the at least one flag to indicate for the second layer that a request for an allocation of the D2D resources is required (1518). In one configuration, the first layer sets the at least one flag by setting a second flag of the at least one flag to indicate that D2D communication is supported (1518). In one configuration, the UE determines from the at least one flag that D2D communication is supported, and that a request for an allocation of the D2D resources is required. In such a configuration, the UE determines the D2D resources by requesting, at the second layer, the first layer to request an allocation of the D2D resources from a serving base station, and by receiving the allocation of the D2D resources from the serving base station, wherein the determined D2D resources are the received allocated D2D resources (1520). In one configuration, the UE determines from the at least one flag that D2D communication is supported, and that a request for an allocation of the D2D resources is required. In such a configuration, the UE determines the D2D resources by requesting, at the second layer, the first layer to request performing D2D communication with a set of D2D resources from a serving base station, and by receiving a confirmation from the base station that the set of D2D resources is reserved for D2D communication (e.g., peer discovery) (1520).

In one configuration, in case 1 c, the system information is determined to have been received for D2D communication (1502), and the set of D2D resources (e.g., common peer discovery resources) is indicated in the system information (1504). In such a configuration, the UE performs D2D communication using the set of D2D resources (1508), stops the D2D communication through the set of D2D resources (1510), and transitions from an RRC idle state to an RRC connected state (1512). In addition, in such a configuration, the at least one flag is set upon transitioning from the RRC idle state to the RRC connected state, and the first layer sets the at least one flag by setting a first flag of the at least one flag to indicate that a request for the allocation of the D2D resources is required (1518). In one configuration, the first layer sets the at least one flag by setting a second flag of the at least one flag to indicate that D2D communication is supported (1518). In one configuration, the UE determines from the at least one flag that D2D communication is supported, and that a request for an allocation of the D2D resources is required. In such a configuration, the UE determines the D2D resources by determining, at the second layer, that no D2D resources are available; by requesting, at the second layer, the first layer to request an allocation of the D2D resources from a serving base station, and by receiving the allocation of the D2D resources from the serving base station (1520). In such a configuration, the determined D2D resources are the received allocated D2D resources.

In one configuration, in case 2c, the system information is determined to have been received for D2D communication (1502), and the set of D2D resources is not indicated in the system information (1504). In such a configuration, the UE performs D2D communication using an allocated set of D2D resources (e.g., an allocated set of peer discovery resources) (1514), and receives a revocation of the use of the allocated set of D2D resources (1516). In such a configuration, the first layer sets the at least one flag by setting a first flag of the at least one flag to indicate that a request for the allocation of the D2D resources is required (1518). In one configuration, the first layer sets the at least one flag by setting a second flag of the at least one flag to indicate that D2D communication is supported (1518). In one configuration, the UE determines from the at least one flag that D2D communication is supported, and that a request for an allocation of the D2D resources is required. In such a configuration, the UE determines the D2D resources by determining, at the second layer, that no D2D resources are available; by requesting, at the second layer, the first layer to request an allocation of the D2D resources from a serving base station, and by receiving the allocation of the D2D resources from the serving base station, wherein the determined D2D resources are the received allocated D2D resources (1520).

In one configuration, in case 3, the system information is determined not to have been received for D2D communication (1502), and the first layer sets the at least one flag by setting a flag of the at least one flag indicating that D2D communication is unsupported, wherein the D2D resources are determined to be a null set (1518). In one configuration, the UE transmits signals in the D2D resources (e.g., peer discovery resources).

FIG. 16is a conceptual data flow diagram1600illustrating the data flow between different modules/means/components in an exemplary apparatus1602. The apparatus1602may be a UE. The apparatus1602includes a receiving module1610that is configured to receive system information for D2D communication. The apparatus1602further includes a system information determination module1612that is configured to determine whether system information is received for D2D communication. The apparatus1602further includes a flag setting module1614that is configured to set at least one flag based on the system information when the system information is received (e.g., information corresponding to peer discovery resources allocated by a base station1640). The apparatus1602further includes a D2D resources determination module (e.g., a peer discovery resources determination module)1616that is configured to determine D2D resources based on the at least one flag. In one configuration, a first layer of the apparatus1602comprises the receiving module1610, the flag setting module1614, and the D2D resources determination module1616, and a second layer of the apparatus1602that is higher than the first layer is configured to check the at least one flag and to request the first layer to determine the D2D resources. In one configuration, the apparatus1602further includes an RRC state determination and control module1618that is configured to determine an RRC state of the apparatus1602, while the system information determination module1612is configured to determine whether a set of D2D resources is indicated in the system information, and while the flag setting module1614is configured to set the at least one flag based on whether the set of the D2D resources is indicated in the system information, and based on the determined RRC state. In one configuration, when the set of D2D resources is determined to be indicated in the system information, and when the RRC state is determined to be an RRC idle state, the flag setting module1614is configured to set a first flag of the at least one flag to indicate for the second layer that a request for an allocation of the D2D resources is unrequired. In one configuration, when the set of D2D resources is determined to be indicated in the system information, and when the RRC state is determined to be an RRC connected state, the flag setting module1614is configured to set a first flag of the at least one flag to indicate that a request for an allocation of the D2D resources is required. In one configuration, when the set of D2D resources is determined to be not indicated in the system information, and when the RRC state is determined to be an RRC idle state, the flag setting module1614is configured to set a first flag of the at least one flag to indicate for the second layer that a request for an allocation of the D2D resources is required. In one configuration, when the set of D2D resources is determined to be not indicated in the system information, and when the RRC state is determined to be an RRC connected state, the flag setting module1614is configured to set a first flag of the at least one flag to indicate for the second layer that a request for an allocation of the D2D resources is required. In one configuration, the apparatus1602further includes a transmission module1620, and when the system information is determined to have been received for D2D communication, and when a set of D2D resources is indicated in the system information, the transmission module1620is configured to perform D2D communication (e.g., with another UE1650) using the set of D2D resources, and is configured to stop the D2D communication through the set of D2D resources, while the RRC state determination and control module1618is configured to transition the apparatus1602from an RRC idle state to an RRC connected state, and while the flag setting module1614is configured to set the at least one flag upon the apparatus1602transitioning from the RRC idle state to the RRC connected state, and is configured to set a first flag of the at least one flag to indicate that a request for the allocation of the D2D resources is required. In one configuration, when the system information is determined to have been received for D2D communication, and when a set of D2D resources is not indicated in the system information, the transmission module1620is configured to perform D2D communication, such as D2D peer discovery communication, using an allocated set of D2D resources, and the receiving module1610is configured to receive a revocation of the use of the allocated set of D2D resources, and the flag setting module1614is configured to set a first flag of the at least one flag to indicate that a request for the allocation of the D2D resources is required.

FIG. 17is a diagram1700illustrating an example of a hardware implementation for an apparatus1602′ employing a processing system1713. The processing system1713may be implemented with a bus architecture, represented generally by the bus1724. The bus1724may include any number of interconnecting buses and bridges depending on the specific application of the processing system1713and the overall design constraints. The bus1724links together various circuits including one or more processors and/or hardware modules, represented by the processor1704, the modules1610,1612,1614, and the computer-readable medium/memory1706. The bus1724may also link various other circuits such as timing sources, peripherals, voltage regulators, and power management circuits, which are well known in the art, and therefore, will not be described any further.

The processing system1713may be coupled to a transceiver1710. The transceiver1710is coupled to one or more antennas1720. The transceiver1710provides a means for communicating with various other apparatus over a transmission medium. The transceiver1710receives a signal from the one or more antennas1720, extracts information from the received signal, and provides the extracted information to the processing system1713. In addition, the transceiver1710receives information from the processing system1713, and based on the received information, generates a signal to be applied to the one or more antennas1720. The processing system1713includes a processor1704coupled to a computer-readable medium/memory1706. The processor1704is responsible for general processing, including the execution of software stored on the computer-readable medium/memory1706. The software, when executed by the processor1704, causes the processing system1713to perform the various functions described supra for any particular apparatus. The computer-readable medium/memory1706may also be used for storing data that is manipulated by the processor1704when executing software. The processing system further includes at least one of the modules1610,1612,1614. The modules may be software modules running in the processor1704, resident/stored in the computer readable medium/memory1706, one or more hardware modules coupled to the processor1704, or some combination thereof. The processing system1713may be a component of the eNB610and may include the memory676and/or at least one of the TX processor616, the RX processor670, and the controller/processor675.

In one configuration, the apparatus1602/1602′ for wireless communication may be a UE. The UE includes means for determining whether system information is received for device-to-device (D2D) communication, means for setting at least one flag based on the system information when the system information is received, and means for determining D2D resources based on the at least one flag.

The UE may further include means for determining whether a set of D2D resources is indicated in the system information, and means for determining a radio resource control (RRC) state of the UE. The at least one flag may be set based on whether the set of the D2D resources is indicated in the system information, and based on the determined RRC state. The means for setting the at least one flag may be configured to set a first flag of the at least one flag to indicate for the second layer that a request for an allocation of the D2D resources is either required, or unrequired, depending on whether the set of D2D resources is determined to be indicated in the system information, and on the determination of the RRC state.

The UE may further include means for performing D2D communication using a set of D2D resources, means for stopping the D2D communication through the set of D2D resources, and means for transitioning from an RRC idle state to an RRC connected state. When the system information is determined to have been received for D2D communication, and when the set of D2D resources is indicated in the system information, the at least one flag is set upon transitioning from the RRC idle state to the RRC connected state, and the means for setting the at least one flag is configured to set a first flag of the at least one flag to indicate that a request for the allocation of the D2D resources is required.

The UE may further include means for performing D2D communication using an allocated set of D2D resources, and means for receiving a revocation of the use of the allocated set of D2D resources. When the system information is determined to have been received for D2D communication, and when the set of D2D resources is not indicated in the system information, the means for setting the at least one flag is configured to set a first flag of the at least one flag to indicate that a request for the allocation of the D2D resources is required.

The aforementioned means may be one or more of the aforementioned modules of the apparatus1602and/or the processing system1713of the apparatus1602′ configured to perform the functions recited by the aforementioned means. As described supra, the processing system1713may include the TX Processor668, the RX Processor656, and the controller/processor659. As such, in one configuration, the aforementioned means may be the TX Processor668, the RX Processor656, and the controller/processor659configured to perform the functions recited by the aforementioned means.