WTRU and a method performed by a WTRU

Abstract

A WTRU and a method performed by the WTRU are provided, the method comprising: using a first set of resources for device-to-device communication, the first set of resources being scheduled by a network; receiving a switching command from the network; and switching from using the first set of resources for device-to-device communication to using a second set of resources for device-to-device communication in response to receiving the switching command, wherein the second set of resources is configured to be used by the WTRU for device-to-device communication under abnormal circumstances.

Description

[0001] This application is a divisional application of the Chinese invention patent with an application date of March 19, 2015, application number 201911031335.9, and title “WTRU and method performed by WTRU”, which is a divisional application of the Chinese invention patent with an application date of March 19, 2015, application number 201580025681.X, and title “Device-to-Device Synchronization”. The entire contents of these divisional applications are incorporated herein by reference.

[0002] CROSS-REFERENCE TO RELATED APPLICATIONS

[0003] This application claims the benefit of U.S. Provisional Application No. 61 / 955,747, filed March 19, 2014, U.S. Provisional Application No. 61 / 955,746, filed March 19, 2014, U.S. Provisional Application No. 61 / 990,049, filed May 7, 2014, U.S. Provisional Application No. 62 / 032,373, filed August 1, 2014, and U.S. Provisional Application No. 62 / 075,524, filed November 5, 2014, the entire contents of which are incorporated herein by reference. Background Art

[0004] Direct device-to-device (D2D) communication can be used in wireless networks. D2D communication can refer to wireless communication transmissions exchanged directly between two or more wireless transmit / receive units (WTRUs), rather than communications routed through a wireless communication infrastructure such as a base station or access point (for example, although the wireless infrastructure can be used to configure D2D sessions and / or schedule D2D transmissions). D2D communication can be used to provide proximity-based services (Pro-Se) in WTRUs. D2D communication provides support for business, social, and public safety communications. The D2D infrastructure can provide consistency in user experience (for example, including availability and mobility). D2D can provide network offload in high traffic cells. For example, D2D can provide support for various services and / or applications when network coverage is limited or unavailable.

[0005] To support public safety communications, there may be a need to coordinate radio access technologies between authorities and reduce the cost of radio access technologies for public safety (PS) officials. For example, first responders may require communications in areas that may not be within the radio coverage of the LTE network. For example, a WTRU may not have coverage in tunnels, basements, or areas where network service has been disrupted due to natural disasters, terrorist attacks, etc. D2D communications may support PS. For example, D2D may provide direct push-to-talk services to first responders who may be handling time-sensitive emergencies.

[0006] D2D communication can be used for commercial purposes, such as by utility companies. For example, D2D communication technology can be used to enhance communications in areas that may have poor coverage from network infrastructure. Business and social users can request D2D communication, for example, to ensure a consistent user experience. For example, users can request D2D communication to improve user availability and / or mobility. Summary of the Invention

[0007] One or more example embodiments described more fully below provide apparatus, functions, steps, processes, execution of one or more computer program instructions tangibly embodying a computer-readable memory, operations, and functions of a method for one or more of the following. To facilitate scheduling of D2D communications, a WTRU may be configured to determine an appropriate scheduling mode for use in D2D communications based on conditions related to radio link coverage of a cellular network, such as a Long Term Evolution (LTE) Evolved Universal Mobile Telecommunications System (UMTS) Terrestrial Radio Access Network (E-UTRAN). For example, the WTRU may determine coverage conditions related to E-UTRAN coverage based on one or more triggering events and / or one or more triggering updates to select an appropriate mode for utilizing D2D resources.

[0008] The WTRU D2D scheduling operation mode may be determined based on one or more triggering events observed at the WTRU. The triggering event may be related to a detected radio condition, or network coverage. The triggering event may be related to the state of a WTRU radio resource control (RRC) timer (e.g., detecting that an RRC timer has been started, detecting that an RRC timer is running, detecting that an RRC timer has been stopped, detecting that an RRC timer has expired, or detecting that an RRC timer has been reset). Examples of RRC timers may include a radio link failure (RLF) timer. For purposes of explanation and illustration, the examples described herein may be described with respect to an RLF timer, but these examples may also apply to RRC timers (and vice versa). Instead of or in addition to performing legacy timer steps upon the occurrence of an RRC-related triggering event, the WTRU may also be configured to switch the D2D operation mode based on the occurrence of an RRC-related triggering event. The WTRU may evaluate and re-evaluate the WTRU operation mode based on different trigger types depending on whether the WTRU is connected to the network or in idle mode. Resource pool selection for WTRU transmission (Tx) and / or reception (Rx) of D2D communications may be performed by the WTRU, and the WTRU may use the message content and one or more configurations of resource pools to select D2D communication parameters, for example, based on a WTRU operating mode change, based on various triggering events, or based on RLF-related triggering events. Time domain D2D transmission and / or reception modes may be configured based on various triggering events.

[0009] The WTRU may determine the type of scheduling mode to use for D2D communication based on detected radio link conditions and / or other triggering conditions associated with the E-UTRAN network. For example, the WTRU may operate in a first scheduling mode for device-to-device communication. In the first scheduling mode, a network entity may schedule resources to be used by the WTRU for device-to-device communication. The WTRU may detect whether a radio link failure (RLF) timer is running or has been started. In response to detecting that the radio link failure timer is running or has been started, the WTRU may switch from the first scheduling mode for device-to-device communication to a second scheduling mode for device-to-device communication. In the second scheduling mode, the WTRU may select resources from a resource pool for the WTRU to use for one or more device-to-device communications.

[0010] For example, the RRC timer may correspond to timer T310. In response to detecting that the number of consecutive unsynchronized transmit time intervals (TTIs) exceeds a threshold, the WTRU may start an RRC timer (e.g., timer T310). In one example, the RRC timer may correspond to timer T311. In response to an RRC connection reestablishment procedure being initiated, the WTRU may start an RRC timer (e.g., timer T311). The RRC timer may correspond to timer T301. Upon expiration of timer T301, the WTRU may cease operation in the second scheduling mode. In response to the WTRU transmitting a radio resource control (RRC) connection reestablishment request message, the WTRU may be configured to start an RRC timer (e.g., timer T301). Starting the RRC timer may trigger the WTRU to change the D2D scheduling mode from the first mode to the second mode. Upon successful RRC connection reestablishment, the WTRU may change the D2D scheduling mode from the second mode to the first mode. Operating the WTRU in the second scheduling mode may include operating the WTRU using fixed power control. Determining to operate as a relay may serve as a trigger. For example, the WTRU may determine to operate as a relay WTRU and begin operating in a second scheduling mode for D2D communications.

[0011] The WTRU may determine the type of scheduling mode to use for D2D communications based on detecting a connection failure with the E-UTRAN network. For example, a WTRU in idle mode may initiate a connection establishment procedure to request D2D resources for transmission. The WTRU may start an RRC timer (e.g., connection establishment timer T300). Upon expiration of the connection establishment timer, the WTRU may determine to use a second scheduling mode. In the second scheduling mode, the WTRU may select resources from a resource pool for the WTRU for one or more device-to-device communications. For example, the WTRU may determine to use the second scheduling mode until it is configured by the network with resources for the first scheduling mode.

[0012] In response to detecting a condition, the WTRU may switch from a first scheduling mode for D2D communication to a second scheduling mode for D2D communication. The WTRU may operate in the first scheduling mode for D2D communication. In the first scheduling mode, a network entity may schedule resources to be used by the WTRU for D2D communication. The WTRU may detect a condition that causes the WTRU to switch from the first scheduling mode for D2D communication to a second scheduling mode. In response to detecting the condition, the WTRU may operate in the second scheduling mode. In the second scheduling mode, the WTRU may select resources from a resource pool for the WTRU to use for D2D communication.

[0013] The WTRU may detect a situation to switch from the first scheduling mode to the second scheduling mode by determining that the WTRU has not selected a cell that supports D2D communication. The WTRU may detect a situation to switch from the first scheduling mode to the second scheduling mode by determining that the WTRU is out of cell coverage. The WTRU may detect a situation to switch from the first scheduling mode to the second scheduling mode by determining that the number of radio link communication (RLC) retransmissions is greater than a threshold.

[0014] The WTRU may detect a condition to switch from a first scheduling mode to a second scheduling mode by detecting a failure to decode a serving cell system information block (SIB) within a time period. The WTRU may detect a condition to switch from a first scheduling mode to a second scheduling mode by determining that the WTRU is in RRC_IDLE mode. In response to switching from the first scheduling mode to the second scheduling mode, the WTRU may switch to using fixed power control.

[0015] The WTRU may be configured to operate in a first scheduling mode for D2D communication. In the first scheduling mode, a network entity may schedule resources to be used by the WTRU for D2D communication. The WTRU may detect a condition to select a second scheduling mode for D2D communication. In the second scheduling mode, the WTRU may select resources from a resource pool for the WTRU for D2D communication. In response to detecting the condition, the WTRU may operate in the second scheduling mode for D2D communication. The WTRU may detect the condition based on one or more triggers described herein. For example, as described herein, the WTRU may detect the condition based on the status of a timer (e.g., an RRC timer, an RLF timer, timer 300, timer 301, timer 310, and / or timer 311). The WTRU may be configured to operate in the first scheduling mode using broadcast signaling or dedicated signaling. The WTRU may detect the condition by determining that the WTRU cannot identify a cell that meets appropriate criteria. When the cell that meets the appropriate criteria cannot be identified, the WTRU may select a pre-configured resource pool associated with the second scheduling mode. Upon determining that timer T310 has expired and timer T311 is not running, the WTRU may be configured to switch from the second scheduling mode to the first scheduling mode.

[0016] A D2D synchronization signal (D2DSS) may be transmitted and / or received by a WTRU. For example, a D2DSS may be communicated using one or more D2D frame configurations. The content of the synchronization frame may be determined based on the D2DSS and / or hop count. The WTRU may use rules for prioritizing synchronization sources and prioritizing data reception. The WTRU may be configured to transmit one or more D2DSSs, which may include a configuration of a preamble and a post-amble. The WTRU may be configured to determine when to stop and / or change the transmission of a D2DSS and / or other types of D2D messages, for example, based on the occurrence of a triggering condition. The WTRU may be configured to determine an appropriate format for a physical D2D synchronization channel (PD2DSCH) transmission, which may include determining the message content, the content of the D2DSS, and / or the conditions for PD2DSCH transmission. BRIEF DESCRIPTION OF THE DRAWINGS

[0017] Figure 1A is a system diagram of an example communication system in which one or more disclosed embodiments may be implemented;

[0018] Figure 1B Yes, you can Figure 1A A system diagram of an example wireless transmit / receive unit (WTRU) for use within a communication system is shown;

[0019] Figure 1C Yes, you can Figure 1AA system diagram of an example radio access network and an example core network for use within the illustrated communication system;

[0020] Figure 1D Yes, you can Figure 1A A system diagram of another example radio access network and an example core network for use within the illustrated communication system;

[0021] Figure 1E Yes, you can Figure 1A A system diagram of another example radio access network and an example core network for use within the illustrated communication system;

[0022] Figure 1F is broadcast by the base station (BS) and distributed to Figure 1A A system diagram illustrating an example of device-to-device synchronization signals for various devices in the communication system;

[0023] Figure 1G yes Figure 1A A system diagram illustrating an example of propagation of a synchronization cluster header (SCH) in two synchronization clusters (eg, two-hop synchronization) within a communication system is shown;

[0024] Figure 2 is a state transition diagram of an example of one or more D2D_CS states configured as sub-states of an existing state machine according to an example embodiment;

[0025] Figure 3 is a system diagram of an example WTRU determining a power control mode based on SIBs when moving to edge coverage or in coverage;

[0026] Figure 4 is a state transition diagram of an example of one or more D2D_CS states configured to be treated as separate state variables or conditions and used to determine actions that can be performed with existing or newly defined steps according to an example embodiment;

[0027] Figure 5 is a diagram of a device-to-device time-domain synchronization frame suitable for implementing one or more example embodiments;

[0028] Figure 6 is a diagram of a device-to-device time-domain and frequency-domain synchronization frame suitable for implementing one or more example embodiments;

[0029] Figure 7 is a diagram of a device-to-device time-domain synchronization frame using multiple frame formats suitable for implementing one or more example embodiments;

[0030] Figure 8 is a view of a device-to-device synchronization source ID suitable for performing one or more example embodiments;

[0031] Figure 9 is a diagram of a device-to-device synchronization signal transmission preamble / postamble suitable for implementing one or more example embodiments;

[0032] Figure 10 is a diagram of an example PD2DSCH-SA timeline and data association compared to a "normal" Scheduling Assignment (SA) timeline and associated data;

[0033] Figure 11 is a diagram of an example PD2DSCH-SA timeline and data association in which a value of an SA associated with a PD2DSCH is set and transmitted in a PD2DSCH transmission subframe;

[0034] Figure 12 is a diagram of an example PD2DSCH-SA timeline and data association in which SA associated with PD2DSCH is transmitted in an SA transmission subframe;

[0035] Figure 13 is a diagram of an example PD2DSCH-SA timeline and data association in which the location of the SA associated to the PD2DSCH is based on an explicit indication carried in the PD2DSCH;

[0036] Figure 14 is an illustration of examples for in-coverage, out-of-coverage, and partial-coverage D2D discovery and / or communication scenarios;

[0037] Figure 15 is an illustration of an example scenario of communication between an in-coverage WTRU and an out-of-coverage WTRU;

[0038] Figure 16 is a diagram of an example of signaling that may be used by an out of coverage WTRU to determine and / or drive resource allocation;

[0039] Figure 17 is an illustration of an example of signaling that may be used by an eNB and / or in-coverage WTRU to determine and / or drive resource allocation. DETAILED DESCRIPTION

[0040] Now, illustrative embodiments will be described in detail with reference to the accompanying drawings.While this description provides specific examples of possible implementations, it should be noted that the details are intended to be illustrative and in no way limit the scope of the application.

[0041] Figure 1Ais a system diagram of an example communication system 100 in which one or more disclosed embodiments may be implemented. The communication system 100 may be a multiple access system that provides content, such as voice, data, video, messaging, broadcast, etc., to multiple wireless users. The communication system 100 may enable multiple wireless users to access the content by sharing system resources, including wireless bandwidth. For example, the communication system 100 may utilize one or more channel access methods, such as code division multiple access (CDMA), time division multiple access (TDMA), frequency division multiple access (FDMA), orthogonal FDMA (OFDMA), single carrier FDMA (SC-FDMA), and the like.

[0042] like Figure 1A As shown, the communication system 100 may include wireless transmit / receive units (WTRUs) 102a, 102b, 102c, and / or 102d (collectively, or collectively, WTRUs 102), radio access networks (RANs) 103 / 104 / 105, core networks 106 / 107 / 109, public switched telephone networks (PSTNs) 108, the Internet 110, and other networks 112. However, it should be understood that the disclosed embodiments encompass any number of WTRUs, base stations, networks, and / or network elements. Each of the WTRUs 102a, 102b, 102c, 102d may be any type of device configured to operate and / or communicate in a wireless environment. By way of example, the WTRUs 102a, 102b, 102c, 102d may be configured to send and / or receive wireless signals and may include user equipment (UE), mobile stations, fixed or mobile subscriber units, pagers, cellular phones, personal digital assistants (PDAs), smart phones, laptops, netbooks, personal computers, wireless sensors, consumer electronics, and the like.

[0043] The communication system 100 may also include a base station 114a and a base station 114b. Each of the base stations 114a, 114b may be any type of device configured to wirelessly interface with at least one of the WTRUs 102a, 102b, 102c, 102d to facilitate access to one or more communication networks (e.g., the core networks 106 / 107 / 109, the Internet 110, and / or the networks 112). By way of example, the base stations 114a, 114b may be a base transceiver station (BTS), a Node B, an eNode B, a Home Node B, a Home eNode B, a site controller, an access point (AP), a wireless router, and the like. Although each of the base stations 114a, 114b is depicted as a single element, it is understood that the base stations 114a, 114b may include any number of interconnected base stations and / or network elements.

[0044] The base station 114a may be part of the RAN 103 / 104 / 105, which may also include other base stations and / or network elements (not shown) such as a base station controller (BSC), a radio network controller (RNC), and relay nodes. The base station 114a and / or the base station 114b may be configured to transmit and / or receive wireless signals within a specific geographic area, which may be referred to as a cell (not shown). A cell may further be divided into cell sectors. For example, the cell associated with the base station 114a may be divided into three sectors. Thus, in one embodiment, the base station 114a may include three transceivers, for example, one transceiver for each sector of the cell. In another embodiment, the base station 114a may employ multiple-input multiple-output (MIMO) technology and, therefore, may utilize multiple transceivers for each sector of the cell.

[0045] The base stations 114a, 114b may communicate with one or more of the WTRUs 102a, 102b, 102c, 102d over an air interface 115 / 116 / 117, which may be any suitable wireless communication link (e.g., radio frequency (RF), microwave, infrared (IR), ultraviolet (UV), visible light, etc.). The air interface 115 / 116 / 117 may be established using any suitable radio access technology (RAT).

[0046] More specifically, as described above, the communication system 100 may be a multiple access system and may employ one or more channel access schemes, such as CDMA, TDMA, FDMA, OFDMA, SC-FDMA, and the like. For example, the base station 114a in the RAN 103 / 104 / 105 and the WTRUs 102a, 102b, 102c may implement a radio technology such as Universal Mobile Telecommunications System (UMTS) Terrestrial Radio Access (UTRA), which may employ Wideband CDMA (WCDMA) to establish the air interface 115 / 116 / 117. WCDMA may include communication protocols such as High Speed Packet Access (HSPA) and / or Evolved HSPA (HSPA+). HSPA may include High Speed Downlink Packet Access (HSDPA) and / or High Speed Uplink Packet Access (HSUPA).

[0047] In another embodiment, the base station 114a and the WTRUs 102a, 102b, 102c may implement a radio technology such as Evolved UMTS Terrestrial Radio Access (E-UTRA), which may establish the air interface 115 / 116 / 117 using Long Term Evolution (LTE) and / or LTE-Advanced (LTE-A).

[0048] In other embodiments, the base station 114a and the WTRUs 102a, 102b, 102c may implement a radio technology such as IEEE 802.16 (i.e., Worldwide Interoperability for Microwave Access (WiMAX)), CDMA2000, CDMA2000 1X, CDMA2000 EV-DO, Interim Standard 2000 (IS-2000), Interim Standard 95 (IS-95), Interim Standard 856 (IS-856), Global System for Mobile communications (GSM), Enhanced Data rates for GSM Evolution (EDGE), GSM EDGE (GERAN), etc.

[0049] Figure 1A The base station 114b in the may be, for example, a wireless router, a Home NodeB, a Home eNodeB, or an access point, and may utilize any suitable RAT for facilitating wireless connectivity in a local area, such as a business district, a home, a vehicle, a campus, or the like. In one embodiment, the base station 114b and the WTRUs 102c, 102d may implement a radio technology such as IEEE 802.11 to establish a wireless local area network (WLAN). In another embodiment, the base station 114b and the WTRUs 102c, 102d may implement a radio technology such as IEEE 802.15 to establish a wireless personal area network (WPAN). In yet another embodiment, the base station 114b and the WTRUs 102c, 102d may utilize a cellular-based RAT (e.g., WCDMA, CDMA2000, GSM, LTE, LTE-A, etc.) to establish a picocell or femtocell. Figure 1A As shown, the base station 114b may have a direct connection to the Internet 110. Thus, the base station 114b may access the Internet 110 without going through the core network 106 / 107 / 109.

[0050] The RAN 103 / 104 / 105 may be in communication with the core network 106 / 107 / 109, which may be any type of network configured to provide voice, data, applications, and / or voice over Internet Protocol (VoIP) services to one or more of the WTRUs 102a, 102b, 102c, 102d. For example, the core network 106 / 107 / 109 may provide call control, billing services, mobile location-based services, pre-paid calling, internet connectivity, video distribution, etc., and / or perform high-level security functions, such as user authentication. Although Figure 1AAlthough not shown, it will be appreciated that the RAN 103 / 104 / 105 and / or the core network 106 / 107 / 109 may be in direct or indirect communication with other RANs, which may employ the same RAT as the RAN 103 / 104 / 105 or a different RAT. For example, in addition to being connected to the RAN 103 / 104 / 105, which may employ an E-UTRA radio technology, the core network 106 / 107 / 109 may also be in communication with another RAN (not shown) employing a GSM radio technology.

[0051] The core network 106 / 107 / 109 may also serve as a gateway for the WTRUs 102a, 102b, 102c, 102d to access the PSTN 108, the Internet 110, and / or other networks 112. The PSTN 108 may include a circuit-switched telephone network that provides plain old telephone service (POTS). The Internet 110 may include a global system of interconnected computer networks and devices that use common communication protocols, such as the Transmission Control Protocol (TCP), User Datagram Protocol (UDP), and Internet Protocol (IP) of the Transmission Control Protocol (TCP) / Internet Protocol (IP) Internet protocol suite. The networks 112 may include wireless or wired communication networks owned and / or operated by other service providers. For example, the networks 112 may include a core network connected to one or more RANs, which may employ the same RAT as the RAN 103 / 104 / 105 or a different RAT.

[0052] Some or all of the WTRUs 102a, 102b, 102c, 102d in the communication system 100 may include multi-mode capabilities. For example, the WTRUs 102a, 102b, 102c, 102d may include multiple transceivers for communicating with different wireless networks via different wireless links. Figure 1A The WTRU 102c shown in FIG. 1 may be configured to communicate with the base station 114a, which may employ a cellular-based radio technology, and with the base station 114b, which may employ an IEEE 802 radio technology.

[0053] Figure 1B is a system diagram of an example WTRU 102. Figure 1BAs shown, the WTRU 102 may include a processor 118, a transceiver 120, a transmit / receive element 122, a speaker / microphone 124, a keypad 126, a display / touchpad 128, non-removable memory 130, removable memory 132, a power supply 134, a global positioning system (GPS) chipset 136, and other peripherals 138. It will be appreciated that the WTRU 102 may include any subcombination of the aforementioned elements while remaining consistent with an embodiment. Similarly, embodiments contemplate that the base stations 114a and 114b and the nodes that the base stations 114a and 114b may represent (such as, but not limited to, transceiver stations (BTSs), Node Bs, site controllers, access points (APs), Home Node Bs, evolved Home Node Bs (eNode Bs), Home evolved Node Bs (HeNBs), Home evolved Node B gateways, and proxy server nodes, etc.) may include Figure 1B Some or all of the elements described in and described herein.

[0054] The processor 118 may be a general purpose processor, a special purpose processor, a conventional processor, a digital signal processor (DSP), a plurality of microprocessors, one or more microprocessors associated with a DSP core, a controller, a microcontroller, an application specific integrated circuit (ASIC), a field programmable gate array (FPGA) circuit, any other type of integrated circuit (IC), a state machine, etc. The processor 118 may perform signal decoding, data processing, power control, input / output processing, and / or any other functionality that enables the WTRU 102 to operate in a wireless environment. The processor 118 may be coupled to the transceiver 120, which may be coupled to the transmit / receive element 122. Although Figure 1B The processor 118 and the transceiver 120 are described in as separate components, but the processor 118 and the transceiver 120 may be integrated together into an electronic package or chip.

[0055] The transmit / receive element 122 may be configured to transmit signals to a base station (e.g., base station 114a) or receive signals from a base station (e.g., base station 114a) via the air interface 115 / 116 / 117. For example, in one embodiment, the transmit / receive element 122 may be an antenna configured to transmit and / or receive RF signals. In another embodiment, the transmit / receive element 122 may be an emitter / detector configured to transmit and / or receive, for example, IR, UV, or visible light signals. In yet another embodiment, the transmit / receive element 122 may be configured to transmit and receive both RF signals and light signals. It will be appreciated that the transmit / receive element 122 may be configured to transmit and / or receive any combination of wireless signals.

[0056] Furthermore, although the transmit / receive element 122 is Figure 1B Although depicted as a single element in the embodiment, the WTRU 102 may include any number of transmit / receive elements 122. More specifically, the WTRU 102 may employ MIMO technology. Thus, in one embodiment, the WTRU 102 may include two or more transmit / receive elements 122 (e.g., multiple antennas) for transmitting and / or receiving wireless signals over the air interface 115 / 116 / 117.

[0057] The transceiver 120 may be configured to modulate signals to be transmitted by the transmit / receive element 122 and to demodulate signals received by the transmit / receive element 122. As described above, the WTRU 102 may have multi-mode capabilities. Thus, the transceiver 120 may include multiple transceivers to enable the WTRU 102 to communicate via multiple RATs, such as UTRA and IEEE 802.11.

[0058] The processor 118 of the WTRU 102 may be coupled to a speaker / microphone 124, a keypad 126, and / or a display / touchpad 128 (e.g., a liquid crystal display (LCD) display unit or an organic light emitting diode (OLED) display unit), and may receive user input data from these devices. The processor 118 may also output user data to the speaker / microphone 124, the keypad 126, and / or the display / touchpad 128. Furthermore, the processor 118 may access information from, and store data in, any type of suitable memory, such as non-removable memory 130 and / or removable memory 132. The non-removable memory 130 may include random access memory (RAM), read-only memory (ROM), a hard disk, or any other type of memory storage device. The removable memory 132 may include a subscriber identity module (SIM) card, a memory stick, a secure digital (SD) memory card, or the like. In other embodiments, the processor 118 may access data from, and store data in, memory that is not physically located on the WTRU 102, such as on a server or a home computer (not shown).

[0059] The processor 118 may receive power from the power source 134 and may be configured to distribute and / or control the power to the other components in the WTRU 102. The power source 134 may be any suitable device for powering the WTRU 102. For example, the power source 134 may include one or more dry cell batteries (nickel-cadmium (NiCd), nickel-zinc (NiZn), nickel-metal hydride (NiMH), lithium-ion (Li-ion), etc.), solar cells, fuel cells, etc.

[0060] The processor 118 may also be coupled to the GPS chipset 136, which may be configured to provide location information (e.g., longitude and latitude) regarding the current location of the WTRU 102. In addition to or in lieu of the information from the GPS chipset 136, the WTRU 102 may receive location information from a base station (e.g., base stations 114a, 114b) over the air interface 115 / 116 / 117 and / or determine its location based on the timing of signals received from two or more neighboring base stations. It will be appreciated that the WTRU 102 may acquire location information using any suitable location-determination method while remaining consistent with an embodiment.

[0061] The processor 118 may also be coupled to other peripherals 138, which may include one or more software and / or hardware modules that provide additional features, functionality, and / or wireless or wired connectivity. For example, the peripherals 138 may include an accelerometer, an electronic compass (e-compass), a satellite transceiver, a digital camera (for photos or videos), a universal serial bus (USB) port, a vibration device, a television transceiver, a hands-free headset, modules, FM radio units, digital music players, media players, video game console modules, Internet browsers, and more.

[0062] Figure 1C FIG1 is a system diagram of the RAN 103 and the core network 106 according to one embodiment. As described above, the RAN 103 may employ a UTRA radio technology to communicate with the WTRUs 102a, 102b, and 102c over the air interface 115. The RAN 103 may also communicate with the core network 106. Figure 1C As shown, the RAN 103 may include Node-Bs 140a, 140b, 140c, each of which may include one or more transceivers for communicating with the WTRUs 102a, 102b, 102c over the air interface 115. Each of the Node-Bs 140a, 140b, 140c may be associated with a particular cell (not shown) in the RAN 103. The RAN 103 may also include RNCs 142a, 142b. It will be appreciated that the RAN 103 may include any number of Node-Bs and RNCs while remaining consistent with an embodiment.

[0063] like Figure 1CAs shown, Node Bs 140a and 140b can communicate with RNC 142a. Additionally, Node B 140c can communicate with RNC 142b. Node Bs 140a, 140b, and 140c can communicate with their respective RNCs 142a and 142b via an Iub interface. RNCs 142a and 142b can communicate with each other via an Iur interface. Each RNC 142a and 142b can be configured to control the respective Node B 140a, 140b, and 140c to which it is connected. Additionally, each RNC 142a and 142b can be configured to perform or support other functions, such as outer loop power control, load control, admission control, packet scheduling, handover control, macrodiversity, security functions, data encryption, and the like.

[0064] Figure 1C The core network 106 shown in FIG. 1 may include a media gateway (MGW) 144, a mobile switching center (MSC) 146, a serving GPRS support node (SGSN) 148, and / or a gateway GPRS support node (GGSN) 150. Although each of the above elements is described as part of the core network 106, it should be understood that any of these elements may be owned and / or operated by an entity other than the core network operator.

[0065] The RNC 142a in the RAN 103 may be connected to the MSC 146 in the core network 106 via an IuCS interface. The MSC 146 may be connected to the MGW 144. The MSC 146 and the MGW 144 may provide the WTRUs 102a, 102b, 102c with access to circuit-switched networks, such as the PSTN 108, to facilitate communications between the WTRUs 102a, 102b, 102c and traditional landline communications devices.

[0066] The RNC 142a in the RAN 103 may also be connected to the SGSN 148 in the core network 106 via an IuPS interface. The SGSN 148 may be connected to the GGSN 150. The SGSN 148 and the GGSN 150 may provide the WTRUs 102a, 102b, 102c with access to packet-switched networks, such as the Internet 110, to facilitate communications between the WTRUs 102a, 102b, 102c and IP-enabled devices.

[0067] As described above, the core network 106 may also be connected to the networks 112, which may include other wired or wireless networks owned and / or operated by other service providers.

[0068] Figure 1D1 is a system diagram of the RAN 104 and the core network 107 according to an embodiment. As described above, the RAN 104 may employ an E-UTRA radio technology to communicate with the WTRUs 102a, 102b, 102c over the air interface 116. The RAN 104 may also be in communication with the core network 107.

[0069] The RAN 104 may include eNode-Bs 160a, 160b, 160c, though it will be appreciated that the RAN 104 may include any number of eNode-Bs while remaining consistent with an embodiment. The eNode-Bs 160a, 160b, 160c may each include one or more transceivers for communicating with the WTRUs 102a, 102b, 102c over the air interface 116. In one embodiment, the eNode-Bs 160a, 160b, 160c may implement MIMO technology. Thus, the eNode-B 160a, for example, may use multiple antennas to transmit wireless signals to, and receive wireless signals from, the WTRU 102a.

[0070] Each of the eNodeBs 160a, 160b, 160c may be associated with a particular cell (not shown) and may be configured to handle radio resource management decisions, handover decisions, scheduling users in the uplink and / or downlink, etc. Figure 1D As shown, the eNode-Bs 160a, 160b, 160c may communicate with one another via an X2 interface.

[0071] Figure 1D The core network 107 shown in FIG may include a mobility management gateway (MME) 162, a serving gateway 164, and a packet data network (PDN) gateway 166. While each of the above elements is described as part of the core network 107, it should be understood that any of these elements may be owned and / or operated by an entity other than the core network operator.

[0072] The MME 162 may be connected to each of the eNode-Bs 160a, 160b, 160c in the RAN 104 via the S1 interface and may serve as a control node. For example, the MME 162 may be responsible for authenticating users of the WTRUs 102a, 102b, 102c, bearer activation / deactivation, selecting a particular serving gateway during an initial attach of the WTRUs 102a, 102b, 102c, and the like. The MME 162 may also provide a control plane function for facilitating switching between the RAN 104 and other RANs (not shown) employing other radio technologies, such as GSM or WCDMA.

[0073] The serving gateway 164 may be connected to each of the eNode-Bs 160a, 160b, 160c in the RAN 104 via an S1 interface. The serving gateway 164 may generally route and forward user data packets to and from the WTRUs 102a, 102b, 102c. The serving gateway 164 may also perform other functions, such as anchoring the user plane during inter-eNode-B handovers, triggering paging when downlink data is available for the WTRUs 102a, 102b, 102c, managing and storing the context of the WTRUs 102a, 102b, 102c, and the like.

[0074] The serving gateway 164 may also be connected to the PDN gateway 166, which may provide the WTRUs 102a, 102b, 102c with access to packet-switched networks, such as the Internet 110, to facilitate communications between the WTRUs 102a, 102b, 102c and IP-enabled devices.

[0075] The core network 107 may facilitate communications with other networks. For example, the core network 107 may provide the WTRUs 102a, 102b, 102c with access to circuit-switched networks, such as the PSTN 108, to facilitate communications between the WTRUs 102a, 102b, 102c and traditional land-line communications devices. For example, the core network 107 may include, or may be in communication with, an IP gateway (e.g., an IP Multimedia Subsystem (IMS) server) that serves as an interface between the core network 107 and the PSTN 108. In addition, the core network 107 may provide the WTRUs 102a, 102b, 102c with access to the networks 112, which may include other wired or wireless networks owned and / or operated by other service providers.

[0076] Figure 1E 1 is a system diagram of the RAN 105 and the core network 109 according to an embodiment. The RAN 105 may be an access service network (ASN) that utilizes IEEE 802.16 radio technology to communicate with the WTRUs 102a, 102b, 102c over the air interface 117. As will be discussed further below, the communication links between the different functional entities of the WTRUs 102a, 102b, 102c, the RAN 105, and the core network 109 may be defined as reference points.

[0077] like Figure 1EAs shown in FIG, the RAN 105 may include base stations 180a, 180b, 180c and an ASN gateway 182, but it will be appreciated that the RAN 105 may include any number of base stations and ASN gateways 182 while remaining consistent with an embodiment. The base stations 180a, 180b, 180c may each be associated with a particular cell (not shown) in the RAN 105 and may include one or more transceivers for communicating with the WTRUs 102a, 102b, 102c over the air interface 117. In one embodiment, the base stations 180a, 180b, 180c may implement MIMO technology. Thus, for example, the base station 180a may use multiple antennas to transmit wireless signals to, and receive wireless signals from, the WTRU 102a. The base stations 180a, 180b, 180c may also provide mobility management functions, such as handover triggering, tunnel establishment, radio resource management, traffic classification, and Quality of Service (QoS) policy enforcement. The ASN gateway 182 may act as a traffic aggregation point and may be responsible for paging, caching subscriber profiles, routing to the core network 109, and the like.

[0078] The air interface 117 between the WTRUs 102a, 102b, 102c and the RAN 105 may be defined as an R1 reference point implementing the IEEE 802.16 specification. Furthermore, each of the WTRUs 102a, 102b, 102c may establish a logical interface (not shown) with the core network 109. The logical interface between the WTRUs 102a, 102b, 102c and the core network 109 may be defined as an R2 reference point, which may be used for authentication, authorization, IP host configuration management, and / or mobility management.

[0079] The communication link between each of the base stations 180a, 180b, 180c may be defined as an R8 reference point that includes protocols for facilitating WTRU handovers and data transfer between the base stations. The communication link between the base stations 180a, 180b, 180c and the ASN gateway 182 may be defined as an R6 reference point. The R6 reference point may include protocols for facilitating mobility management based on mobility events associated with each of the WTRUs 102a, 102b, 102c.

[0080] like Figure 1EAs shown, the RAN 105 may be connected to a core network 109. The communication link between the RAN 105 and the core network 109 may be defined, for example, as an R3 reference point, including protocols for facilitating data transfer and mobility management capabilities. The core network 109 may include a mobility IP home agent (MIP-HA) 184, an authentication, authorization, and accounting (AAA) server 186, and a gateway 188. While each of the above elements is depicted as part of the core network 109, it should be understood that any of these elements may be owned and / or operated by an entity other than the core network operator.

[0081] The MIP-HA may be responsible for IP address management and may enable roaming for the WTRUs 102a, 102b, 102c between different ASNs and / or different core networks. The MIP-HA 184 may provide the WTRUs 102a, 102b, 102c with access to packet-switched networks, such as the Internet 110, to facilitate communications between the WTRUs 102a, 102b, 102c and IP-enabled devices. The AAA server 186 may be responsible for user authentication and supporting user services. The gateway 188 may facilitate interworking with other networks. For example, the gateway 188 may provide the WTRUs 102a, 102b, 102c with access to circuit-switched networks, such as the PSTN 108, to facilitate communications between the WTRUs 102a, 102b, 102c and traditional land-line communications devices. In addition, the gateway 188 may provide the WTRUs 102a, 102b, 102c with access to the networks 112, which may include other wired or wireless networks that are owned and operated by other service providers.

[0082] Although Figure 1E Although not shown, it will be appreciated that the RAN 105 may be connected to other ASNs, and the core network 109 may be connected to other core networks. The communication link between the RAN 105 and the other ASNs may be defined as an R4 reference point, which may include protocols for coordinating the mobility of the WTRUs 102a, 102b, 102c between the RAN 105 and the other ASNs. The communication link between the core network 109 and the other core networks may be defined as an R5 reference point, which may include protocols for facilitating interworking between a home core network and a visited core network.

[0083] review Figures 1A to 1E, it should be understood that the communication system 100 may include synchronization signals (SS) (not shown) broadcast by the base stations 114a and 114b to the WTRUs 102a, 102b, 102c, and 102d over the air interfaces 115, 116, and 117. The SS may allow the WTRUs 102a, 102b, 102c, and 102d to determine time and frequency parameters for demodulating downlink signals and transmitting uplink signals with correct timing, as well as determining whether the target cell supports frequency division duplexing (FDD) or time division duplexing (TDD). These synchronization signals may be designated as a primary synchronization signal (PSS) and a secondary synchronization signal (SSS). Further, as Figures 1A to 1G As shown, it will be appreciated that according to one or more embodiments, the WTRUs 102a, 102b, 102c, 102d and WTRUs 102e, 102f, 102g, 102h, 102i, and 102j may support device-to-device (D2D) communication between two or more adjacently located WTRUs. Accordingly, a D2D synchronization signal (D2DSS) may be broadcast between the D2D-enabled WTRUs, with one designated as a primary D2D synchronization signal (P-D2DSS) and one designated as a secondary D2D synchronization signal (S-D2DSS).

[0084] Figure 1F 10 is a system diagram illustrating an example of a synchronization cluster head (SCH) and a D2DSS broadcast by a base station (BS). The BS and / or SCH transmitting the D2DSS may be referred to as a synchronization source (SS). The D2DSS may be relayed to a synchronization cluster head (SCH), such as, as described herein, SCH 103 and / or WTRUs 102e, 102f, 102g, 102h, 102i, and 102j. The SCH may be a synchronization source other than a base station (e.g., an eNB) that does not obtain synchronization for transmission from another synchronization source or sources. A non-SCH WTRU receives the D2DSS from the SCH and / or base station. A non-SCH WTRU may become a synchronization source by transmitting the D2DSS based on synchronization obtained from the SCH or base station. The WTRU may communicate the D2DSS using a sidelink synchronization signal. The WTRU may communicate the D2DSS using two sidelink synchronization signals. For example, the WTRU may communicate the D2DSS using a primary sidelink synchronization signal and a secondary sidelink synchronization signal.

[0085] Figure 1G is a system diagram showing an example propagation of SCH synchronization in two synchronization clusters (e.g., in synchronization zones 1 and 2). Figure 1A The communication system shown performs an example of two-hop synchronization. Figure 1G An example two-hop synchronization is shown, but SCH synchronization may be propagated for more than two hops.

[0086] Specifically, Figure 1F An example of a distributed synchronization scheme is shown, where a serving base station (S-BS) may broadcast an indication of one or more D2D resource pools to one or more WTRUs discovered and communicating within its own cell (e.g., cell 1) for reception and / or transmission. A receiver disposed in the WTRU may determine a time and / or frequency reference, such that, for example, a receiver window and frequency correction may be aligned when a D2D channel is detected and / or transceiver timing and parameters may be aligned when a D2D channel is transmitted. Figure 1F As shown, the example embodiments described below provide information to a WTRU that is exposed to D2D channels transmitted by neighbor WTRUs stationed in different cells (e.g., N-BS in cell 2), PLMNs (not shown), and clusters (e.g., SCH synchronization cluster 1). WTRUs stationed on neighboring cells, PLMNs, and / or clusters may signal their own D2D resource pools along with their synchronization reference to allow detection of D2D communication resources. This objective is met by the various synchronization protocols described below according to one or more example embodiments. In other words, the WTRU may relay the synchronization reference and the D2D resource pools monitored by neighbor WTRUs. Additionally, the example embodiments may allow the WTRU to perform direct transmissions to retransmit synchronization signals to other neighboring WTRUs to allow synchronization of potential receivers in the network (e.g., and outside the network coverage area).

[0087] A D2D-enabled WTRU may perform various operations based on the state of the WTRU. Example states may include the location of the WTRU in the network, whether a neighboring WTRU is near the WTRU, radio resource control (RRC) state, D2D configuration, and / or the like. For example, mode selection (e.g., scheduling mode selection) may be performed when the WTRU moves out of coverage of a cell. The WTRU may, for example, start / stop relay synchronization based on certain circumstances. An example may be that the WTRU may select a synchronization source based on certain circumstances or that the WTRU may select a resource pool based on the same or other circumstances. The WTRU may determine whether to transmit a D2DSS and / or relay a PD2DSCH message based on the same or other circumstances. The WTRU may relay a PSBCH (Physical Sidelink Broadcast Channel) message that may include a Master Information Block-SL (Master Information Block-SL) message. In other words, a D2D-enabled WTRU may determine multiple parameters to perform D2D communication based on the detected radio link conditions. The D2D-enabled WTRU may initiate steps to evaluate or re-evaluate these parameters when there is a change in the WTRU state. For example, a change in the WTRU's location in the network, a change in the identity of a nearby neighboring WTRU, a change in RRC state, a D2D configuration update, and / or the like may trigger the WTRU to evaluate which scheduling mode to use and / or whether to relay synchronization signals. Non-limiting example scenarios are provided herein that may describe operations and steps that may be performed by a D2D-enabled WTRU.

[0088] A D2D-enabled WTRU may determine the resources that the D2D-enabled WTRU may use for D2D communications. The resources may depend on the scheduling mode in which the WTRU is operating. For example, the WTRU may operate in Mode 1. In Mode 1, the WTRU may dynamically request resources from a network entity (e.g., a base station or eNB). In Mode 1, which may be referred to as a scheduling mode of operation, the eNB may schedule the resources that the WTRU may use for D2D transmissions. The WTRU may operate in Mode 2, which may be referred to as a WTRU-selected scheduling mode. In Mode 2 (e.g., WTRU-selected mode), the WTRU may autonomously select D2D resources for use from one or more resource pools that may be semi-statically signaled by the network or pre-configured in the WTRU. As described herein, the WTRU may determine whether to select Mode 1 or Mode 2 based on network configuration and / or one or more conditions or triggers, for example, in response to detecting that an RRC timer is running or has been started. The WTRU may select a resource pool based on the WTRU's current conditions (e.g., RRC state, coverage status, channel conditions, etc.).

[0089] A D2D-enabled WTRU may determine when to transmit (e.g., initiate or forward) a D2D synchronization signal (D2DSS) and / or a D2D synchronization message (PD2DSCH). The WTRU may determine when to transmit one or more D2DSSs and / or D2D synchronization messages based on nearby nodes that the WTRU may detect, configuration parameters, and / or other triggers described herein.

[0090] A D2D-enabled WTRU may select a primary synchronization source (MSS). The MSS may be a base station (e.g., an eNodeB). The MSS may be another D2D-enabled WTRU that may use a reference timing to support D2D operations. The D2D-enabled WTRU may perform MSS selection or reselection based on updates to the WTRU's situation (e.g., detection of D2D neighbor nodes and / or WTRU mobility).

[0091] A D2D-enabled WTRU may determine the resource pools that the WTRU may use for D2D transmission and reception. For example, the WTRU may use network-provided resources or pre-configured resources depending on its configuration and situation (e.g., when the WTRU is in Mode 1). The WTRU may stop using pre-configured resources (e.g., due to mobility or network reconfiguration) and obtain resources from the serving cell base station or eNB (e.g., when the WTRU transitions from Mode 2 to Mode 1). A D2D-enabled WTRU may determine that network conditions have changed and may perform resource pool selection / reselection based on the changed network conditions.

[0092] A D2D-enabled WTRU may determine a time pattern for reception and transmission of D2D communications and / or exchange information with a second WTRU, for example, to ensure that a pair of WTRUs can communicate with each other. When a D2D-enabled WTRU in coverage detects an out-of-coverage WTRU in the vicinity of a D2D-enabled WTRU in coverage, the D2D-enabled WTRU in coverage may initiate the steps of providing a time domain transmission and / or reception pattern.

[0093] The WTRU may identify resources that the WTRU may monitor for discovery and communication. For example, the WTRU may monitor resources associated with a serving cell or cluster. The WTRU may monitor resources associated with a neighboring cell, cluster, or PLMN. The WTRU may determine the coverage situation of the WTRU. For example, the WTRU may determine whether the WTRU is in coverage, edge of coverage, or out of coverage. In determining the coverage situation, the WTRU may utilize one or more triggering events (e.g., one or more RRC timers, such as one or more RLF timers). The WTRU may determine the coverage situation by detecting one or more trigger updates associated with the coverage situation. The WTRU may detect a trigger update by detecting one or more trigger events.

[0094] The WTRU may select resources based on the coverage situation of the WTRU. The coverage situation (e.g., each coverage situation) may be associated with WTRU resources and the WTRU may select resources associated with the coverage situation of the WTRU. The WTRU may determine an operating mode (e.g., a scheduling mode for D2D communication) based on, for example, one or more triggering events. An example triggering event may include detecting that an RRC timer (e.g., an RLF timer) is running or has been started. The WTRU may determine a scheduling mode for D2D communication based on additional triggering events. The WTRU may select one or more resource pools for the WTRU to transmit (Tx) and / or receive (Rx). Resource pool selection may include message content and configuration of resource pools based on various triggering events. The WTRU may select one or more resource pools that have been forwarded to other WTRUs.

[0095] The WTRU may configure a time domain D2D transmission and / or reception pattern, for example, based on various triggering events. The WTRU may perform D2DSS transmission and / or D2DSS reception, for example, based on one or more D2D frame configurations. The WTRU may determine the content of the synchronization frame from the D2DSS and the hop count. The WTRU may use rules for prioritizing synchronization sources. The WTRU may use rules for prioritizing data reception, for example, based on different synchronization sources. The WTRU may transmit the D2DSS. The D2DSS transmission may include configuration of a preamble and / or a postamble. The WTRU may determine when to stop or change the transmission of the D2DSS or a message. The WTRU may format a physical D2D synchronization (PD2DSCH), for example, to include the content of the message, the rules for determining the content, the content of the D2DSS, and / or the circumstances under which the PD2DSCH is transmitted.

[0096] The WTRU may determine the coverage situation of the WTRU based on a triggering event that may be associated with the coverage situation. For example, the WTRU may determine whether the WTRU is in coverage, marginal coverage, or out of coverage, for example, by determining that a timer (e.g., an RRC timer, such as an RLF timer) is running or has been started.

[0097] The WTRU may determine the coverage situation by determining one or more triggered updates of the WTRU's coverage situation. The WTRU may determine the triggered update by detecting one or more triggering events associated with the triggered update. The WTRU may determine the coverage situation based on the WTRU's proximity to a cell that may transmit radio frequency signals. Example cells may include LTE cells (e.g., macro cells), pico cells, femto cells, or the like. For example, when the WTRU is located within a cell boundary, the WTRU may determine that the WTRU is in coverage. When the WTRU is near a cell edge, the WTRU may determine that the WTRU is not in coverage. When the WTRU is located near a cell edge, the WTRU may determine that the WTRU is in edge coverage. When the WTRU is neither in coverage nor in edge coverage, the WTRU may determine that the WTRU is out of coverage.

[0098] The WTRU may be configured to initiate evaluation or re-evaluation of various D2D operation parameters, for example, when there is a change in the WTRU's coverage situation. For example, the D2D operation parameters may include resource pools, operation modes (e.g., D2D scheduling mode, D2D operation mode, e.g., relay WTRU, remote WTRU, or normal WTRU), synchronization transmission, synchronization source selection, or the like.

[0099] The WTRU may detect a change in coverage by detecting one or more event triggers. The WTRU may detect triggers based on measurements. For example, the WTRU may be configured to determine its coverage by measuring signals received from one or more base stations (e.g., eNBs). The WTRU may be configured to determine whether the WTRU is in coverage or edge coverage by comparing a measured reference signal received power (RSRP) value or a received signal strength indication (RSSI) value of its associated cell (e.g., a serving cell) with one or more thresholds stored in a memory. For example, if the measured RSRP value or the measured RSSI value is greater than a preconfigured threshold, the WTRU may determine that the WTRU is in coverage. A measured RSRP value or RSSI value greater than a preconfigured threshold may indicate that the signal power is greater than the threshold. For example, based on the absence of an RSSI or RSRP signal value, the WTRU may determine that the WTRU is in an out of coverage situation.

[0100] A WTRU may determine whether it is in coverage, in edge coverage, or out of coverage by comparing the measured RSRP value of its associated cell (e.g., serving cell) with the measured RSRP values of one or more cells (e.g., neighboring cells). For example, if the WTRU determines that the RSRP value of its associated cell exceeds the RSRP measurements from other cells by a preconfigured value, the WTRU may determine that it is in coverage or in edge coverage. For example, when the RSRP value of its associated cell is within a preconfigured range (the preconfigured range is larger than the preconfigured range of RSRP measurements from other cells), the WTRU may determine that the WTRU is in coverage or in edge coverage. For example, based on the absence of an RSSI or RSRP signal value, the WTRU may determine that the WTRU is in an out of coverage situation.

[0101] A WTRU may determine whether it is in coverage or edge coverage. A WTRU may determine whether it is in coverage or edge coverage based on the presence of hysteresis. A WTRU may determine whether it is in coverage or edge coverage based on the time of a trigger, measurements that the WTRU may make within a time period, and / or the like. A WTRU may be configured to avoid undesirable ping-pong effects. A WTRU in edge coverage may refer to a WTRU that is close to the edge of a cell associated with the WTRU (e.g., the edge of a serving cell).

[0102] The WTRU may determine its coverage based on an event trigger (e.g., by detecting an event trigger). When event A3 is triggered with a positive or negative value (e.g., an offset value) of the cell range expansion (CRE) deviation, the WTRU may determine that it is in edge coverage. The WTRU may determine that it is in edge coverage by comparing the measured RSRP or reference signal received quality (RSRQ) value of its associated cell with that of a neighboring cell. For example, when the difference between the RSRP / RSRQ values of the serving cell and the neighboring cell is equal to or less than the configured CRE deviation, the WTRU may determine that the WTRU is in edge coverage.

[0103] A WTRU may be configured to determine a coverage situation by detecting an event trigger that may be based on a D2D resource (grant) request failure. When the number of random access channel (RACH) failures reaches a preconfigured threshold, the WTRU may determine that it is in edge coverage of the cell. A WTRU in coverage may initiate a RACH for sending a scheduling request (SR) and / or a buffer status report (BSR) to request resources for D2D transmission. The WTRU may determine that it is in edge coverage, for example, if the number of RACH attempts exceeds a preconfigured threshold. The WTRU may be configured to determine that it is in edge coverage, for example, if the number of SRs exceeds a preconfigured threshold. The WTRU may be configured to determine that it is in edge coverage when the WTRU does not receive a grant within a configured duration since sending a first SR that may have triggered a D2D transmission. The WTRU may determine that it is in edge coverage when the WTRU does not receive a grant within a configured duration after sending a BSR for D2D resources. For example, if the retxBSR timer expires after the transmission of a BSR for D2D communication, the WTRU may determine that it is in edge coverage. The WTRU may determine that it is in edge coverage after a predetermined number of retransmissions of the initial BSR. A WTRU in edge coverage may be configured to attempt (e.g., periodically attempt) uplink communication.

[0104] A WTRU may determine its coverage condition by detecting an event trigger that may be based on HARQ A / N feedback. A WTRU may determine that it is in marginal coverage, for example, if the Hybrid Automatic Repeat Request (HARQ) negative feedback for an uplink transmission is greater than, less than, or equal to a configured threshold. For example, a WTRU in coverage may be configured to determine that it is in marginal coverage when the number of NACKs received in a certain window (e.g., time period) reaches or exceeds a configured threshold.

[0105] The WTRU may determine its coverage situation by detecting an event trigger which may be based on an RLF situation. The WTRU may determine that it is in edge coverage, for example, if one or more specified triggers cause the WTRU to detect a radio link failure (RLF) situation. For example, when an RRC timer is started, for example, when timer T310 or T312 is started or expires, the WTRU may determine that it is in edge coverage. The WTRU may be configured to determine that it is in edge coverage based on a preconfigured number of times it is out of sync or is out of sync (e.g., N TTIs) in a row. The WTRU may determine that it is in edge coverage, for example, if a radio resource control (RRC) re-establishment procedure is triggered or initiated. If a re-establishment timer (e.g., an RRC timer) is started, for example, if timer T311 is started or T301 is started, the WTRU may determine that it is in edge coverage.

[0106] When the RRC re-establishment procedure is triggered or initiated, the WTRU may start a timer (e.g., an RRC timer, e.g., an RLF timer), such as timer 311 or timer 301. The WTRU may determine that it is in marginal coverage, for example, if a command to re-establish RRC is transmitted. The WTRU may determine that it is in coverage, for example, if the RRC re-establishment procedure is successful. The WTRU may determine that it is in marginal coverage when the number of radio link control (RLC) retransmissions becomes equal to or exceeds a pre-configured threshold. The WTRU may determine that it is in marginal coverage when the number of radio link control (RLC) retransmissions is within a pre-configured value range.

[0107] The WTRU may determine the coverage situation of the WTRU by detecting an event trigger based on the cell applicability criteria. When the WTRU does not find a cell that meets one or more predetermined applicability criteria, the WTRU may determine that it is in an out of coverage situation. The WTRU may determine that the cell is applicable, for example, if the cell advertises support for D2D communication. An edge coverage WTRU may determine that it is in an out of coverage situation when the WTRU cannot, for example, decode the serving cell system information block (SIB) within a predetermined time window. For example, when a transition to RRC_IDLE any-cell-select is detected, the WTRU may determine the coverage situation of the WTRU.

[0108] The WTRU may determine its coverage by detecting an event trigger that may be based on a D2D synchronization signal / channel. The WTRU may determine that it is in an out-of-coverage condition by detecting one or more neighboring WTRUs that may be able to relay D2D resource pool information. Upon entering the Camped_on_D2DUE state, the WTRU may determine that it is in an out-of-coverage state. The Camped_on_D2DUE state may indicate that a D2D-enabled WTRU was able to successfully decode a control message carrying D2D configuration information from a neighboring WTRU.

[0109] An in-coverage WTRU may be configured to initiate transmission of synchronization signals and / or messages, for example, once the in-coverage WTRU detects a D2DSS from a neighboring out-of-coverage WTRU.

[0110] The WTRU may evaluate and / or re-evaluate whether the WTRU becomes a synchronization source and / or relay. Figure 5 、 Figure 6 and Figure 7 As shown in , upon receiving D2D synchronization signals, a WTRU may select and / or reselect a new synchronization source. A WTRU may evaluate / re-evaluate its primary synchronization source, for example, if the WTRU detects a new neighboring WTRU that is transmitting one or more alternate D2D synchronization signals with better signal strength.

[0111] The WTRU may determine its coverage condition by detecting an event trigger, which may be based on downlink channel conditions. The WTRU may determine its coverage condition based on one or more detected downlink signal errors. The WTRU may detect an event trigger, for example, if the downlink block error rate (DL BLER) is less than, equal to, or exceeds a configured threshold. In response to the DL BLER being less than, equal to, or exceeding a configured threshold, the WTRU may determine that it is in marginal coverage.

[0112] The WTRU may determine its coverage situation by detecting an event trigger, which may be based on a handover event. The WTRU may determine its coverage situation based on one or more mobility events. The WTRU may detect an event trigger, for example, if a mobility event is triggered (e.g., event A3), or if a (Radio Resource Control) RRC reconfiguration message with mobility control information is received, which may enable the WTRU to determine that it is in marginal coverage situation. For example, when an event trigger is detected when an RRC reconfiguration complete message is successfully transmitted by lower layers, the WTRU may determine that the WTRU is in coverage situation.

[0113] The WTRU may determine its coverage situation by detecting an event trigger that may be based on a periodic UL procedure. The WTRU may determine its coverage situation by periodically attempting to perform one or more uplink procedures to determine whether it can transition from another coverage situation to a coverage situation. For example, the WTRU may periodically attempt to perform one or more uplink procedures. The WTRU may determine that it is in coverage, for example, if the uplink procedure is successful.

[0114] A WTRU may determine its coverage status based on its current status information. The WTRU may maintain status information based on its current location relative to a base station or one or more eNBs and / or other D2D-enabled WTRUs. The WTRU may select an operating mode and resource pool based on the status information. The WTRU may receive an explicit indication of its coverage status, for example, from the network. The WTRU may determine its coverage status implicitly.

[0115] A WTRU may determine its D2D coverage state. A D2D-enabled WTRU may be configured into one of the following states, for example, based on its coverage situation. The state information may be referred to as D2D-Coverage State (D2D_CS). The D2D_CS may include a D2D_CS referred to as being in coverage. A WTRU may be in coverage when it is in RRC_IDLE and camped on an appropriate cell. A WTRU may be in coverage when it is in RRC_CONNECTED mode, served by a cell supporting D2D services, and the WTRU determines that the edge coverage condition is not satisfied.

[0116] The WTRU may determine that it is in edge coverage. D2D_CS may include a D2D_CS sub-state called edge coverage. The WTRU may be in edge coverage when it has an unreliable link and / or cannot exchange request / response communications with the base station or eNB in downlink and / or uplink unicast. For example, the WTRU may decode DL system information from the base station or eNB because DL system information may be relatively more robust than normal unicast communications. The WTRU may be in RRC_IDLE or RRC_CONNECTED state (e.g., when the WTRU is in edge coverage).

[0117] The WTRU may determine that it is out of coverage. D2D_CS may include a D2D_CS substate called out of coverage. When the WTRU cannot find a serving cell that meets the cell applicability criteria, the WTRU may determine that it is in the out of coverage state. When the WTRU cannot find a serving cell that supports D2D services, the WTRU may determine that it is in the out of coverage state. If the WTRU cannot find a suitable cell and is in any cell selection state, the WTRU may determine that it is in the out of coverage state. The WTRU may be configured to search (e.g., periodically search) for a suitable cell in the configured PLMN. The out of coverage WTRU may operate in the EMM-registered no-cell-available or EMM-deregistered no-cell-available state.

[0118] The WTRU may be configured to determine sub-states. The out of coverage state of a D2D-enabled WTRU may include two or more sub-states. For example, a sub-state of the out of coverage state may be the D2D_Camped on UE state. The WTRU may be in the D2D_Camped on UE state when the WTRU cannot be located in an appropriate cell but the WTRU has successfully decoded D2D configuration information transmitted by another WTRU (which may be a covered WTRU that relays / transmits information from the network). A sub-state of the out of coverage state may be the No_D2D Source state. The WTRU may be in the No_D2D Source state when the WTRU does not find an appropriate cell that supports D2D services and / or a neighboring WTRU that is transmitting D2D configuration information.

[0119] Figure 2 1 is a state transition diagram illustrating an example embodiment in which the D2D_CS state may include, for example, sub-states of an existing state machine. Figure 4 As shown, the D2D_CS state may be viewed as a separate state variable or condition. The WTRU may use the D2D_CS state to determine one or more actions that may be performed using existing or newly defined procedures. The WTRU may use the D2D_CS state to determine one or more transmission modes to be used by the WTRU when the separate state variable or condition is met.

[0120] The WTRU may be configured to determine its coverage status by detecting updates regarding triggering events. The WTRU may be configured to determine its coverage status by detecting independent triggers. The WTRU may trigger an evaluation / re-evaluation of its coverage status based on one or more triggering events described herein. For example, when the WTRU is in a certain state, the WTRU may monitor the situation to determine the coverage status or the operating mode to use.

[0121] The WTRU may be configured to determine the coverage state based on a trigger from a base station or eNB command. The WTRU may trigger an evaluation / re-evaluation of its coverage situation based on a command received from the base station or eNB. Upon successful RLF re-establishment, the base station or eNB may send a command to the D2D-enabled WTRU in edge coverage to transition back to the in coverage state. The WTRU may implicitly determine that it is in coverage upon completion (e.g., successful completion) of the re-establishment procedure or upon performing an RRC connection establishment. For example, upon successful completion of the re-establishment procedure, the WTRU may be configured to attempt to operate in coverage. The transition to in coverage may trigger the WTRU to send an uplink message (e.g., a service or RRC request, a dedicated RACH request, or a scheduling request). The WTRU may continue to operate as a WTRU in coverage, for example, if the uplink procedure is successful. If the uplink procedure is unsuccessful, the WTRU may revert to edge coverage or out of coverage state.

[0122] Upon a change in coverage state, the WTRU may be configured to perform one or more steps. For example, upon a change in coverage state, the WTRU may be configured to determine a mode of operation (e.g., a scheduling mode for D2D communications) that the WTRU may use to acquire D2D resources (e.g., Mode 1 or Mode 2). For example, the WTRU may detect a change in edge coverage and the WTRU may transition to Mode 2 transmission. For example, the WTRU may detect a change in the WTRU's coverage situation and the WTRU may assume the role of a primary synchronization source (MSS). Upon assuming the role of the MSS, the WTRU may begin transmitting synchronization signals (e.g., transmitting a D2DSS and / or synchronization messages via the PD2DSCH).

[0123] The WTRU may be configured to perform resource selection upon detecting a change in coverage status. The D2D-enabled WTRU may perform a resource selection step to determine resources for D2D transmission and / or reception. The D2D-enabled WTRU may determine D2D resources, which are physical resource blocks (PRBs) in time and frequency, for D2D operation. The D2D-enabled WTRU may be configured with one or more D2D resources, such as a D2D resource pool. The D2D-enabled WTRU may select a mode of transmission and a timing of reception from the resource pool within a defined duration based on the D2D resource selection. The mode may include a D2D transmission mode and / or a D2D reception mode.

[0124] The WTRU may be configured to perform WTRU resource selection steps upon entering an in-coverage situation. A D2D-enabled WTRU that transitions from a network out-of-coverage area or a network edge coverage area to a network in-coverage area may be configured to transmit a report. The report may include a request to perform D2D communication and / or a state change. The D2D-enabled WTRU may identify network coverage or situations via triggering events as described herein.

[0125] A D2D-enabled WTRU that transitions from a network out of coverage area or a network edge coverage area to a network in coverage area, or a D2D-enabled WTRU that switches to a new cell, may stop transmitting in existing resources N from the previous operating mode (e.g., the previous D2D scheduling mode) or cell. For example, a WTRU that switches from mode 1 to mode 2 may stop transmitting in existing resources from mode 1. The WTRU may determine the network configuration for the D2D communication mode for D2D devices within the cell (e.g., by reading one or more system information blocks (SIBs) or using the existing configuration of the cell in the D2D-enabled WTRU). The WTRU may connect to the network (e.g., register). The D2D-enabled WTRU may request resources for D2D transmission, for example, after connecting to the network. If the WTRU is configured for mode 1, the WTRU may connect to the network. If no configuration is available, the WTRU may connect to the network. For example, if the cell indicates that the cell is D2D capable, the WTRU may connect to the network. When in a network out of coverage area or a network edge coverage area, the WTRU may stop using Mode 2 transmission resources that the WTRU may have been using.

[0126] A D2D-enabled WTRU transitioning from a network out of coverage or network edge coverage to a network in coverage may identify the resources M, resource pattern, and / or transmission pattern allowed for in coverage transmissions, for example, based on one or more of the following. The WTRU may use a predetermined mapping between N and M signaled on a SIB. The WTRU may use a configured or received transmission resource pool (for example, if available from the eNB's SIB, or via RRC signaling). The WTRU may continue to use the previous transmission pool, for example, if there is an explicit indication by the network to continue the existing configuration. The WTRU may use an explicit indication received from the network (for example, via RRC signaling or a medium access control (MAC) control element (CE) or via a physical downlink control channel (PDCCH) using specific downlink control information (DCI)). The WTRU may use a transmission timing pattern or a configured transmission pool from the eNB.

[0127] A D2D-enabled WTRU that transitions from a network out of coverage or network edge coverage area to a network in coverage area may identify new resources, a temporal pattern, and / or allowed reception opportunities for in coverage reception, for example, based on at least one of the following. The WTRU may identify resources using an explicit receive resource pool received from the network (e.g., via RRC signaling, via a MAC CE, or via a PDCCH using specific DCI). The WTRU may identify resources using a pre-configured resource pool for reception and / or a mapping predetermined based on a provided configuration (e.g., a temporal pattern calculated based on a WTRU-specific identifier). A D2D-enabled WTRU that transitions from a network out of coverage or network edge coverage area to a network in coverage area may send a report to the eNB indicating the results of the resource selection process based on the steps described herein.

[0128] The WTRU may perform a resource selection step when entering an edge coverage state. A WTRU transitioning from a network coverage area to a network edge coverage area may be configured to identify network coverage, for example, by detecting a triggering event as described herein. The WTRU may stop transmitting in existing resources N or may stop transmitting when a grant expires (for example, at the end of a scheduling period). The WTRU may read a system information block (SIB) and determine the network configuration for the D2D communication mode. The WTRU may select Mode 2, for example, if the WTRU is configured to operate in Mode 2 or is allowed to operate in Mode 2, or if no configuration is available.

[0129] A WTRU transitioning from a network coverage area to a network edge coverage area may identify new resources M for edge coverage transmission, for example, based on at least one or more of the following. The WTRU may identify the new resources based on a predetermined mapping between N and M signaled on a SIB. The WTRU may identify the new resources based on a resource configuration from the SIB. The WTRU may identify the new resources based on a resource pool preconfigured for transmission. The WTRU may identify the new resources based on a time pattern used for transmission (e.g., a transmission pool). The WTRU may determine a time pattern from the SIB, a preconfigured pattern, and / or a predetermined mapping based on a provided configuration (e.g., a time pattern calculated based on a WTRU-specific identifier). A WTRU transitioning from a network coverage area to a network edge coverage area may identify new resources for edge coverage reception, for example, based on at least one or more of the following. The WTRU may identify the new resources based on a resource configuration from the SIB. The WTRU may identify the new resources based on a resource pool preconfigured for reception. The WTRU may identify the new resources based on a time pattern used for transmission. The WTRU may select a time mode from a time mode obtained from the SIB, a pre-configured mode, and / or a predetermined mapping based on a provided configuration (eg, a time mode calculated based on a WTRU-specific identifier).

[0130] A WTRU transitioning from a network coverage area to a network edge coverage area may initiate an UL message, for example, to determine a change in the current state (e.g., to determine whether the WTRU can be moved back into coverage mode). Initiating an UL message may include reading the SIB to determine the periodic message configuration (e.g., RACH configuration, periodic BSR configuration, timeout window duration, gap between consecutive attempts, etc.). Initiating an UL message may include performing a periodic transmission to the network with the configured configuration.

[0131] A WTRU may be configured to perform resource selection when entering an out of coverage state. A WTRU transitioning from a network coverage area to a network edge coverage area may identify network coverage as described herein. The WTRU may stop transmitting in existing resources N or using an existing scheduling mode and determine a new set of resources to be used and a new scheduling mode. The WTRU may listen to neighboring eNBs and check for applicability. The applicability check may include checking whether the cell supports D2D services. In the event that no applicable cell is found, the WTRU may listen to any neighboring D2D synchronization signal. The WTRU may evaluate the applicability of the D2DSS based on one or more D2D WTRU applicability criteria. The applicability criteria may include source ID priority (e.g., if the source ID is prioritized), hop count, and / or the like. A WTRU transitioning from a network coverage area to a network edge coverage area may initiate one or more Mode 2 transmission steps. The WTRU may identify new resources M for out of coverage or edge coverage transmissions, for example, based on at least one of the following. The WTRU may identify new resources based on a predetermined configuration for scheduling assignments and D2D transmissions. For example, the WTRU may receive the configuration by reading the SIB. The WTRU may identify the new resource based on a time pattern used for transmission, a mapping predetermined based on a provided configuration (e.g., a time pattern calculated based on a WTRU-specific identifier). The WTRU may identify the new resource based on a pre-configured pattern (e.g., a pre-configured resource), for example, if provided. The WTRU may identify the new resource for in-coverage reception, for example, based on at least one of: a pre-configured resource pool for reception, a time pattern to be used for reception, a mapping predetermined based on a provided configuration (e.g., a time pattern calculated based on a WTRU-specific identifier), and / or a pre-configured pattern.

[0132] The WTRU may initiate an UL message to determine the change in the current state. The WTRU may initiate an UL message by reading the SIB to determine the periodic message configuration (e.g., RACH configuration, periodic BSR configuration, timeout window duration, gap between consecutive attempts, or the like) and periodic transmissions to the network with the configured attempts.

[0133] The WTRU may be configured to select the type of power control mode upon coverage change.A WTRU may be configured with one or more power control modes to operate with D2D communications.

[0134] The WTRU may be configured with a closed-loop power control mode. For example, a node (e.g., an eNB, a cluster head, or a control node, etc.) may control the WTRU's transmit power for D2D communication and / or discovery. The WTRU may select a power control mode that may be based in part on a closed-loop approach. For example, the WTRU may receive a power signal indication from a node (e.g., an eNB, a cluster head, or a control node, etc.) using a power control command. The WTRU may receive a power control signal, for example, as part of a D2D communication grant control signal (e.g., via a PDCCH, an ePDCCH, and / or other control signal) and / or the like.

[0135] The WTRU may be configured with open loop power control (e.g., to a reference node). The WTRU may determine its power based on, for example, one or more measurements of RSRP from a node (e.g., a reference node, a control node, an eNB, a D2D WTRU, a synchronization source, a cluster head, etc.). For example, the WTRU may estimate the path loss to a node, for example, based on a node transmit power value and measurement that may be determined or pre-configured based on control signaling such as a SIB in the case of an eNB. The WTRU may adjust the power to achieve a minimum or maximum received power at the node. The WTRU may be configured with a power control mode based on parameters (e.g., on a USIM). The node (e.g., an eNB, a D2D WTRU, a synchronization source, a cluster head, etc.) may configure the parameters for power control, for example, via RRC signaling or on a SIB.

[0136] The WTRU is configured with a fixed power control mode. The WTRU may be configured with a fixed transmit power. The WTRU may be configured with a transmit power parameter, for example, from the USIM or via RRC / SIB. The transmit power parameter may be fixed. For example, the WTRU may be configured with multiple fixed transmit power parameters, for example, separate values associated with the configured operating range of the D2D service. The WTRU may select a value from the multiple transmit power values, for example based on the configured range. The discovery service may be configured with an operating range (e.g., short, medium, long). The WTRU may select a transmit power for transmitting, for example, a D2D discovery payload based on the operating range. The WTRU may obtain the D2D discovery payload and / or the operating range as an indication from higher layers.

[0137] The WTRU may be configured to perform power control related actions when changing coverage status.The WTRU may be configured to determine the D2D power control mode, for example, based on the D2D WTRU coverage situation.

[0138] Communication between a WTRU and an eNB may apply to communication between a WTRU and a node (e.g., a source node, a control node, a cluster head, a synchronization source, a D2D WTRU, etc.). Communication between a WTRU and a node (e.g., a source node, a control node, a cluster head, a synchronization source, a D2D WTRU, etc.) may apply to communication between a WTRU and an eNB.

[0139] The WTRU may be configured to change its power control mode to a fixed power control mode, such as when moving out of coverage. The WTRU may be configured to change its power control mode autonomously (e.g., when it detects that it is out of network coverage or out of coverage of a node and / or reference node). For example, the WTRU is configured to autonomously change its power control mode to fixed power control when moving out of coverage. The WTRU may be configured to determine power control parameters based on configuration. The WTRU may be configured to maintain parameters configured by the network. The WTRU may use configuration parameters forwarded from an in-coverage D2D WTRU, such as provided by a node associated with the in-coverage WTRU (e.g., an eNB, a control node, a reference node, a cluster head, a D2D WTRU, a synchronization source, etc.).

[0140] Figure 3 A system diagram may depict an example of a WTRU determining a power control mode based on a SIB when moving to edge coverage or in coverage. A WTRU may be configured to determine a power control mode based on a SIB when moving to edge coverage and / or in coverage. A WTRU may be configured to autonomously change its power control mode when it detects that it has moved into the coverage of a node (e.g., an eNB, a control node, a reference node, a cluster head, a D2D WTRU, a synchronization source, etc.). For example, a WTRU may be configured to change its power control mode to an open-loop power control mode (e.g., a reference node power control mode) using the closest eNB and / or serving eNB as a reference node. The WTRU may use power control parameters received from the eNB's SIB or from the node's broadcast control.

[0141] The WTRU may determine the power control mode to use by reading the configuration on the SIB when moving into the coverage of a node (e.g., eNB, control node, reference node, cluster head, D2D WTRU, synchronization source, etc.). The WTRU may receive an indication on the SIB to use fixed power control with associated parameters such as power parameters for SA transmissions, D2D data and / or discovery transmission power, and / or the like.

[0142] The WTRU may be configured via the SIB, for example, to use closed-loop power control. For example, when using closed-loop power control, the WTRU may be configured to attempt to connect to a node (e.g., an eNB, a control node, a reference node, a cluster head, a D2D WTRU, a synchronization source, etc.). For example, during a time when a connection fails or the WTRU is attempting to connect, and / or similar situations, the WTRU may be configured to use open-loop power control with parameters configured on the SIB.

[0143] The WTRU may be configured via the SIB to use, for example, open loop power control with parameters signaled on the SIB.

[0144] The WTRU may be configured to determine a power control mode based on a configuration from the network, for example, when in coverage. The WTRU may be configured to connect to the network. The WTRU may be configured to receive a power control configuration, for example, via dedicated RRC signaling, such as when the WTRU moves into network coverage. The WTRU may be configured to use fixed power control, for example, during times when the WTRU is not connected. The WTRU may be configured to use parameters signaled on a SIB, for example, during times when the WTRU is not connected.

[0145] The WTRU may be configured to determine a power control mode based on a D2D operation mode (e.g., a D2D scheduling mode, such as Mode 1 or Mode 2). For example, the WTRU may evaluate and / or select a power control mode that may be used when the WTRU changes the D2D operation mode. For example, when the WTRU switches from Mode 1 to Mode 2 (e.g., when the RRC connection is released), the WTRU may move from closed-loop power control to open-loop power control and / or fixed power control. For example, when the WTRU switches from Mode 1 to Mode 2 (e.g., when the RRC connection is released), the WTRU may use one or more parameters signaled on the SIB.

[0146] The WTRU may be configured to determine a power control mode based on a transition of roles. The WTRU may evaluate and select a power control mode that may be used when the WTRU, for example, starts operating as a synchronization source or cluster head or stops operating as an MSS or cluster head. For example, the WTRU may operate in a closed-loop power control mode in which at least some transmit power parameters are obtained from a reference node, such as when the WTRU is operating as a normal WTRU that acquires synchronization from a reference node (e.g., a synchronization source or cluster head). The WTRU may change the power control mode to fixed power control, for example, due to a change in circumstances, such as if the WTRU decides to start operating as a synchronization source. The WTRU may use parameters configured in the WTRU, for example, due to a change in circumstances, such as if the WTRU decides to start operating as a synchronization source.

[0147] The WTRU may be configured to select an operating mode (e.g., a scheduling mode for D2D communications). If the WTRU is in the RRC_CONNECTED state, the WTRU is performing D2D communications using Mode 1 scheduling (e.g., the eNB schedules D2D transmissions), and if the WTRU detects a connection problem, the WTRU may determine that a radio link failure (RLF) situation has occurred based on existing triggers. The WTRU may attempt to recover the link (e.g., by attempting to perform a re-establishment). However, there may be some delay while the WTRU is attempting to recover the link. For example, repeated out-of-sync indications in the downlink may trigger an RRC timer (e.g., an RLF timer, such as Timer T310 or Timer T312) that may have a large value (e.g., up to 2s). Thresholds for detecting uplink problems may include large values to avoid frequency ping-pong, but these may result in long delays if the WTRU cannot communicate with the network, cannot obtain authorization for D2D, and / or cannot perform important D2D communications. To avoid such interruptions, the D2D WTRU may continue to operate during that time frame. The WTRU may be configured to determine a problem (eg, by detecting that T310 is running) and transition to Mode 2 resource selection.

[0148] The base station or eNB and the WTRU may determine a change in circumstances and trigger the WTRU to change its steps to obtain D2D resources. The WTRU may determine a change in circumstances and trigger the WTRU to change its steps to obtain D2D resources (eg, switching from Mode 1 to Mode 2).

[0149] The WTRU may evaluate / re-evaluate the D2D operation mode based on a trigger (e.g., a situation). The WTRU may be configured to select a scheduling mode based on an independent trigger. The WTRU may trigger the evaluation / re-evaluation of its operation mode (e.g., Mode 1 or Mode 2) based on one or more triggering events (e.g., situations) described herein. The WTRU may use Mode 2 resources when the WTRU detects (e.g., determines) that it is in an out of coverage state. The WTRU may determine that it is in an out of coverage state when the WTRU cannot find a cell that meets the cell applicability criteria and / or when the WTRU cannot detect a cell. For example, the WTRU may use Mode 2 resources when it cannot decode the serving cell SIB within a predetermined time window. The WTRU may use Mode 2 resources when the WTRU transitions to RRC_IDLE.Any-Cell-Selection. The WTRU may use Mode 2 resources when the WTRU determines a change in coverage state based on the start or expiration of an RRC timer (e.g., timer T300). When the WTRU determines that a re-establishment procedure has been initiated (e.g., when an RRC timer starts or expires, such as when T311 or T301 starts or expires), the WTRU may use Mode 2 resources. If the RRC connection request procedure fails, the WTRU may use Mode 2 resources.

[0150] The WTRU may be configured to perform mode selection / switching procedures based on a trial / fallback approach. If using D2D resources, the WTRU may attempt to use the mode configured by the base station or eNB. If the WTRU does not successfully acquire resources within the configured duration, the WTRU may fall back to a semi-static or pre-configured resource pool using Mode 2.

[0151] A WTRU camped (e.g., RRC_IDLE or RRC CONNECTED) on an appropriate serving cell may be configured to initiate D2D resource selection using Mode 1. When new D2D data arrives, the WTRU may initiate a request to obtain resources from the base station or eNB. If this step is unsuccessful, the WTRU may attempt to use Mode 2 with a resource pool configured using broadcast signaling. If no resources are available in the broadcast signaling or no resources are configured (e.g., explicitly) for Mode 2 operation, the WTRU may not perform D2D operation. If no resources are signaled or the WTRU cannot decode the SIB, it may transition to Mode 2 with a pre-configured resource pool.

[0152] The WTRU may be configured to establish an RRC connection and may request resources for D2D operations. The WTRU may be configured to establish an RRC connection by receiving a signal from the eNB via the SIB D2D configuration. When D2D data (e.g., new D2D data) arrives, the WTRU in RRC_IDLE mode may initiate an RRC connection establishment procedure. If the RRC connection establishment procedure is unsuccessful, the WTRU may attempt to use the configured Mode 2 resources. The WTRU may use the configured Mode 2 resources in specified circumstances, such as one or more of the following circumstances.

[0153] The WTRU may be configured to operate in Mode 2 and use Mode 2 resources when a timer is running or expires (e.g., when T300 is running or expires (e.g., when transmitting an RRC Connection Request)). The WTRU may use Mode 2 resources when an RRC Connection Reject is received. The WTRU may use Mode 2 resources when T302 (e.g., T-Block) is running (e.g., when an RRC Connection Reject is received when performing an RRC Connection Establishment). The WTRU may use Mode 2 resources when T303 or T305 is running (e.g., when access is blocked when performing an RRC Connection Establishment for a mobile originating call or signaling). The WTRU may use Mode 2 resources, for example, if the WTRU is configured to notify higher layers of a failure to establish an RRC connection. The WTRU may use Mode 2 resources when an access blocked check in RRC determines that a cell is blocked and / or after a timer (e.g., a new timer) expires. The timer may have been initiated when the RRC Connection Request was initiated. The timer may be started when the RRC Connection Request was initiated. The timer may be stopped when the RRC Connection Setup is received. Upon receiving the RRC Connection Setup or upon receiving an indication from higher layers to stop transmission, the WTRU may use Mode 1 operation or use a network provided configuration.

[0154] For example, the WTRU may send a BSR to request authorization for D2D transmission. The WTRU may attempt to use Mode 2, for example, if the WTRU does not receive a response from the eNB within a time period. A timer may be started, for example, when the BSR is triggered and / or sent. The WTRU may be triggered to transition to Mode 2, for example, by the expiration of a timer. The WTRU may be triggered to transition to Mode 2 by the expiration of a timer (such as a retxBSR timer). The WTRU may start Mode 2, for example, after multiple retransmissions of a D2D BSR.

[0155] The WTRU may send an SR to request authorization, for example, as a result of a D2D BSR triggering. The WTRU may transition to using Mode 2, for example, if the WTRU does not receive PUSCH resources to transmit a BSR. The WTRU may transition to using Mode 2, for example, if the D2D BSR does not include an assembled MAC PDU within a defined duration. A timer may be started when a D2D BSR is triggered and / or when an SR is transmitted. Expiration of the timer may trigger the WTRU to transition to Mode 2. For example, if the WTRU retransmits an SR more than a configured number of times, the WTRU may transition to Mode 2. The WTRU may be triggered to transition to Mode 2 transmission by expiration of the SR-prohibit timer. For example, a WTRU using Mode 2 transmission may be configured to attempt (e.g., periodically) uplink communication. The WTRU may be configured to periodically attempt UL communication, such as if the WTRU remains in connected mode and / or if the network has configured the WTRU for Mode 1 transmission. The WTRU may reattempt communication (e.g., periodically and / or if a BSR is triggered). The WTRU may wait for a period of time before attempting communication.

[0156] The WTRU may be configured to perform a mode selection / switching procedure based on expiration of a resource grant duration. The WTRU may detect resource grant deactivation, for example, if the mode selection / switching procedure is not triggered based on expiration of the resource grant duration. The WTRU may be configured with information about selecting a mode, for example, if D2D resources are used. The WTRU may be configured with information about resource pools, for example, when D2D resources may be invalid and / or may become invalid. For example, the WTRU may be configured with D2D resources that may be valid for a duration (for example, a duration during which the resources may be considered valid). The WTRU may be configured to perform a mode switch, for example, upon expiration of the duration. The duration may be configured, for example, in a resource time manner based on time, frame number, subframe number, etc. The WTRU may be configured to switch modes, for example, from mode 1 to mode 2, such as when mode 1 resources are deactivated by the network.

[0157] The WTRU may switch from Mode 1 to Mode 2 based on the absence of a response to a BSR transmission. For example, the WTRU may send a BSR to request permission for D2D transmission. The WTRU may attempt to use Mode 2, for example, if the WTRU does not receive a response from the eNB within a certain time. A timer may be started when the BSR is sent. The WTRU may be configured to transition from Mode 1 to Mode 2 upon expiration of an existing timer, retxBSRTimer.

[0158] The WTRU may be configured to perform mode selection / switching procedures based on RRC state transitions. If D2D resources are used, the WTRU may be configured with rules for selecting a mode and resource pool based on the RRC state. The WTRU may be configured to operate in Mode 2 when it is in RRC_Idle Mode. The WTRU may be configured with rules that override base station or eNB defined modes.

[0159] The WTRU may be configured to perform mode selection / switching procedures based on D2D coverage state changes. The WTRU may be configured with rules for selecting a mode and resource pool based on the current D2D coverage state. The WTRU may detect a state change based on one or more triggering events described herein.

[0160] When the WTRU determines that it is in coverage, it may be configured to obtain resource pools and mode configurations for D2D transmissions. The WTRU may receive resource pool and mode configuration information via a signaled configuration that may be received from a base station or eNB. A WTRU operating in edge coverage may be configured to obtain resource allocations from the network and perform autonomous resource selection for D2D transmissions. A WTRU operating in an out of coverage state (e.g., no D2D source available) may use pre-configured resource allocations and may perform autonomous resource selection. A WTRU operating in out of coverage that is camped on another UE may obtain resource pools for control messages from one or more neighboring WTRUs and perform autonomous resource selection based on the control configuration.

[0161] The WTRU may be configured to perform mode selection / switching based on one or more base station or eNB commands. The base station or eNB may send a mode selection command with the mode to be used for the WTRU in the cell using dedicated or broadcast signaling. The base station or eNB may send a mode selection command with one or more resources and modes to be used for the WTRU in the cell using dedicated or broadcast signaling. The base station or eNB may send the mode selection command as an RRC message, a layer 2 message, and / or a layer 1 message (e.g., PDCCH). The WTRU may request resources from the network in mode 1. The WTRU may send a layer 1 message that may instruct the WTRU to transition to mode 2. The network may indicate (e.g., explicitly indicate) whether the WTRU is attempting mode 1 operation or mode 2 operation. When the WTRU is configured for mode 1 operation, one or more of the situations described herein may trigger the WTRU to transition to mode 2 operation.

[0162] When a WTRU in coverage is triggered to perform D2D communication, the WTRU may send a request to the base station or eNB to request one or more resources, and the base station or eNB may respond with a mode (e.g., Mode 1 or Mode 2) in which the WTRU may operate.

[0163] The WTRU may receive rules to perform mode selection for D2D communication. For example, a base station or eNB may use broadcast signaling to signal rules indicating the modes that may be used for all WTRUs in a cell.

[0164] The WTRU may be configured to perform mode selection / switching based on UL success. For example, a WTRU operating in Mode 2 may be configured to evaluate / re-evaluate the resource selection mode when RACH is successful. A WTRU operating in Mode 2 may be configured to evaluate / re-evaluate the resource selection mode when an UL grant is received within a configured duration after a scheduling grant is sent.

[0165] The WTRU may be configured to perform mode selection / switching based on the expiration of a time alignment timer (TAT). For example, a WTRU operating in Mode 1 may be configured to evaluate / re-evaluate the mode when the WTRU misses timing with the network. The WTRU may be configured to transition to Mode 2, for example, when the WTRU is triggered by the expiration of a TAT (e.g., a time alignment timer).

[0166] The WTRU may be configured to perform other steps after selecting a scheduling mode for D2D communication.A WTRU in Mode 2 may select a pre-configured resource pool or resources configured by a base station or eNB.

[0167] A WTRU mode selection change may trigger the WTRU to send an indication to a node, for example, so that the network may release resources. For example, the WTRU may send an indication to the eNB, such as when the WTRU moves from Mode 1 to Mode 2. The indication to the eNB may include a method that the WTRU may use when it begins Mode 2 operation. A WTRU configured with active Mode 1 (e.g., semi-static) resources may not use and / or need the resources at a certain point (e.g., if no data remains to be transmitted). The WTRU may autonomously release and / or deactivate resources (e.g., Mode 1 resources), for example, when configured for Mode 2. The WTRU may send an indication to the eNB that the WTRU has released the resources. The WTRU may wait for an indication from the network to release the resources. The eNB may release the resources and / or provide an indication to the WTRU to release and / or deactivate the resources, such as when the indication from the WTRU is used to indicate that the resources are no longer occupied and / or needed. The indication may allow the eNB to perform management of the resources.

[0168] The WTRU may be configured to release Mode 1 resources by releasing the grant and / or not performing a D2D transmission (e.g., if the WTRU has no data to transmit but may have an active grant). For example, the WTRU may cause a MAC CE to indicate to the network that it has released Mode 1 resources. The WTRU may use a buffer status report with a low buffer size (e.g., set to zero) to indicate that the WTRU may not use the resources and / or has released the grant. In some examples, the WTRU may send an indication when it releases the resources (e.g., after a number of consecutive MAC PDUs each containing a zero MAC SDU are provided to D2D data traffic following an implicit release), such as for a semi-persistent resource allocation.

[0169] The WTRU may be configured with one or more steps to change the scheduling mode for D2D communications. As discussed herein, the WTRU may be configured by the eNB to use Mode 1 resources (e.g., using RRC signaling) and may begin using Mode 2 resources in response to one or more conditions described herein. The one or more conditions may include resource configuration, authorized application type, authorized usage area, index ID, control and / or data usage. The one or more conditions may include activation / deactivation triggers, time windows, measurement-based triggers, and / or cell range expansion-based triggers. The one or more conditions may include D2D resource grant request failure, HARQ A / N feedback. The one or more conditions may include triggers based on RLF conditions. The WTRU may be configured to detect an RLF condition by detecting that a timer (e.g., RRC timer, timer 310, timer 311, and / or timer 301) is running or has been started. The one or more conditions may include cell suitability criteria, D2D synchronization signal / channel, downlink channel condition, handover event, and / or triggering a periodic uplink procedure. The WTRU may be configured to use and / or request Mode 1 resources unless a failure condition is detected.

[0170] A WTRU in connected mode may be configured with steps for changing the scheduling mode for D2D communications. One or more triggers may indicate the start of Mode 2 operation and / or may indicate that the WTRU is considered to be in a failure condition (e.g., a radio link failure (RLF) condition, such as when an RRC timer (e.g., an RLF timer, such as T310, T311, or T301) is running or has been started).

[0171] An RRC_Connected WTRU may be configured to detect a failure condition (e.g., an RLF condition, e.g., by detecting that an RRC timer is running). When an RRC_Connected WTRU has D2D data to transmit and is configured to request Mode 1 resources, if the RRC_Connected WTRU cannot obtain Mode 1 resources due to one or more conditions or triggers described herein, the RRC_Connected WTRU may detect a failure condition (e.g., a condition of switching from Mode 1 to Mode 2) when one or more of the following conditions are met. The RRC_Connected WTRU may detect a condition when a grant fails to be received after a predetermined duration after a D2D BSR is sent. The RRC_Connected WTRU may detect a condition when a grant fails to be received after a predetermined duration after a D2D SR is sent. The RRC_Connected WTRU may detect a condition when one or more RLF triggers are met (e.g., RACH failure, RLC retransmission failure, etc.). The RRC_Connected WTRU may detect a condition when T310 is running or expires (e.g., detecting N out-of-sync TTIs). An RRC_Connected WTRU may detect when T311 is running (eg, detect that an RRC connection re-establishment procedure has been initiated). An RRC_Connected WTRU may detect when T301 is running (eg, detect that a request to re-establish an RRC connection has been transmitted).

[0172] When the WTRU detects a failure condition (e.g., a condition switching from Mode 1 to Mode 2), the WTRU may start Mode 2 operation. The WTRU may detect a failure condition and may start Mode 2 operation, for example, if an RRC re-establishment procedure is initiated (e.g., an RRC timer is running, such as T311 or T301 is running) while the WTRU has UL D2D data to transmit.

[0173] A WTRU in Mode 2 operation may continue to use Mode 2 until one or more of the following occurs: the WTRU has data to transmit, the WTRU receives an RRC re-establishment message from the network and the re-establishment is completed, the WTRU receives an RRC re-establishment message, T301 stops, the WTRU transitions to idle mode (e.g., when an RRC timer stops or expires, e.g., when T311 or T301 stops or expires, or an RRC connection rejection occurs), and / or a timer expires and the WTRU attempts (e.g., re-attempts) access to the network or attempts (e.g., re-attempts) an authorization request.

[0174] The WTRU may be configured to cease operating in Mode 2 upon successful re-establishment. Upon successful receipt of the re-establishment message, the WTRU may cease using Mode 2 operation and may cease D2D data transmission until explicit configuration is received from the serving eNB. The RRC re-establishment message may include D2D configuration information. The WTRU may resume D2D data transmission based on the D2D configuration information included in the RRC re-establishment message.

[0175] The WTRU may use Mode 2 resources until RRC re-establishment is successful. Upon successful receipt of the re-establishment message, the WTRU may continue Mode 2 operation until the WTRU has successfully completed RRC re-establishment (e.g., an RRC re-establishment complete message has been transmitted). Upon completing the re-establishment procedure, the WTRU may begin operating using the configuration provided in the re-establishment procedure. If the re-establishment procedure is unable to provide a D2D configuration (e.g., a new D2D configuration) upon completing the re-establishment procedure, the WTRU may stop performing D2D data transmission until an explicit configuration is received in an RRC configuration message (e.g., if the cell indicates that the WTRU needs to request Mode 1 operation). Upon completing the re-establishment procedure, the WTRU may continue using Mode 2 until the RRC re-configuration message provides the WTRU with a D2D configuration to use.

[0176] The WTRU may be configured to transition to idle mode if re-establishment is unsuccessful. If the re-establishment procedure is unsuccessful and the WTRU transitions to idle mode, the WTRU may perform one or more of the following. If the re-establishment procedure is unsuccessful and the WTRU transitions to idle mode, the WTRU may continue to perform Mode 2 operation (e.g., if data is still available) and may notify one or more higher layers of the unsuccessful re-establishment (e.g., failure). If the re-establishment procedure is unsuccessful and the WTRU transitions to idle mode, the WTRU may notify one or more higher layers that D2D data transmission is continuing. One or more higher layers may trigger a service request (e.g., a new service request) and an RRC connection establishment procedure (e.g., a new RRC connection establishment procedure) in which D2D data is being transmitted using Mode 2. If the re-establishment procedure is unsuccessful and the WTRU transitions to idle mode, the WTRU may stop D2D data transmission, may stop operating in Mode 2, and may notify one or more higher layers of the unsuccessful re-establishment (e.g., failure). One or more higher layers may initiate (e.g., immediately initiate) an RRC connection request to request service for the D2D application. If the re-establishment procedure is unsuccessful and the WTRU transitions to idle mode, the WTRU may perform one or more of the WTRU procedures described herein for idle mode.

[0177] The WTRU may be configured to detect a failure condition in idle mode. When the WTRU is in idle mode, the WTRU may trigger Mode 2 operation and / or the WTRU may detect a failure condition. When an RRC_Idle WTRU has D2D data to transmit and is configured to request Mode 1 resources, the WTRU may initiate an RRC Connection Request to request D2D services and configuration. The WTRU may not be able to successfully perform an RRC connection and may not be able to perform D2D data transmission. The WTRU may detect a failure condition (e.g., a condition of switching from Mode 1 to Mode 2) when one or more of the following conditions are met. The WTRU may detect a condition when T300 expires (e.g., a request to establish an RRC connection is unsuccessful). The WTRU may detect a condition when an RRC Connection Reject or RRC Connection Release is received, or when T302 or T-Block is running (e.g., an RRC Connection Reject message is received when performing an RRC Connection Establishment). The WTRU may detect a condition when the Access Blocked Check in RRC determines that a cell is blocked. The WTRU may detect a situation when T303 or T305 is running (e.g., access is blocked when performing RRC connection establishment for mobile originated call / signaling). The WTRU may detect a situation when the WTRU must notify one or more higher layers of a failure to establish an RRC connection. The WTRU may detect a situation after the expiration of a timer that was initiated when the RRC connection request was initiated. The timer may be started when the RRC connection request was initiated. The timer may be stopped when the RRC connection establishment message is received.

[0178] The WTRU may select from the Mode 2 resources identified by the network. When the WTRU is in idle mode, the WTRU may use broadcast Mode 2 resources to start using Mode 2. The WTRU may start using Mode 2 operation when it detects one or more failure conditions described herein. The network may broadcast a set of Mode 2 D2D resources that a WTRU in a failure condition may use in idle mode. For example, a set of Mode 2 D2D resources may be reserved for use by WTRUs in failure conditions (e.g., a WTRU that has not experienced a failure condition may not be allowed to use these resources). The network may broadcast an indication that the WTRU is using Mode 1 under normal circumstances (e.g., attempting to connect to the network).

[0179] When the WTRU is in idle mode, the WTRU may start using pre-configured Mode 2 resources. For example, the network may not broadcast Mode 2 resources (e.g., if the network commands all idle mode WTRUs to perform Mode 1 access). When the WTRU is in idle mode, the WTRU may initiate D2D data transmission using the pre-configured set of resources to transmit (e.g., without stopping) higher priority D2D data transmissions (e.g., D2D emergency data services, such as public safety services). When performing D2D data transmission using the pre-configured set of resources, the WTRU may be configured to re-tune back to the network's resources to monitor and ensure proper reception of paging messages.

[0180] When the WTRU is in idle mode, the WTRU may retry the RRC connection request access according to an RRC retry timer (e.g., a new RRC retry timer). For example, a timer (e.g., a D2D abnormal state timer) may be defined by the network or the WTRU to retry connection and / or request to the network, for example, to request D2D resources from the network. The timer may be started when one or more triggers described herein are met. When the timer is started, the WTRU may start using configured Mode 2 resources (e.g., Mode 2 resources configured for use during abnormal scenarios). Upon expiration of the timer, the RRC may be configured to retry sending a request to establish a connection (e.g., RRC_IDLE) or request authorization (e.g., RRC_CONNECT) in the uplink. The RRC may be configured to start a timer and continue to retry connection to the network for a preconfigured number of times (e.g., a maximum number of attempts) before signaling a failure to one or more higher layers.

[0181] When the WTRU is in idle mode, the WTRU may interact with higher layers when RRC connection establishment fails. When the WTRU is in RRC_idle mode and fails to establish a connection with the network (e.g., the WTRU detects the failure according to any of the conditions specified herein), the WTRU may be configured to indicate the failure to one or more higher layers (e.g., NAS or ProSe client) and may start performing D2D data transmission using Mode 2 resources. The WTRU may notify one or more higher layers (e.g., NAS or ProSe client) that the WTRU is configured to perform D2D data transmission using Mode 2, even though one or more higher layers may not have received a service request response. The one or more higher layers (e.g., NAS or ProSe client) may retry the connection based on existing mechanisms (e.g., when the application is allowed to continue transmitting). The WTRU may be configured to continue using Mode 2 resources until Mode 1 resources become available (e.g., until RRC connection establishment with a cell supporting D2D communication is successful).

[0182] When the WTRU is in idle mode and the WTRU interacts with higher layers when RRC connection establishment fails, the WTRU may continue Mode 2 transmission of D2D data until one or more of the following conditions are met. The WTRU may continue Mode 2 transmission of D2D data until a subsequent RRC connection request is successfully completed. When the RRC connection is completed, the WTRU may act according to the serving cell configuration or the dedicated configuration provided (e.g., Mode 1 or Mode 2). The WTRU may continue Mode 2 transmission of D2D data until an RRC connection request message (e.g., a new RRC connection request message) is initiated. The WTRU may stop using Mode 2 and may stop performing D2D transmissions until the steps are successful or one or more of the failure conditions described herein are met. The WTRU may continue Mode 2 transmission of D2D data until no D2D data has been transmitted for a predetermined period of time. One or more higher layers (e.g., NAS or application layer) may be notified that the WTRU has stopped Mode 2 transmission. If new data arrives, a service request (e.g., a new service request) may be triggered. If the application is terminated by the user, the WTRU may continue Mode 2 transmission of D2D data when the WTRU moves out of Mode 2 transmission. An application (e.g., a new application) or data (e.g., new data) may trigger the WTRU to initiate an RRC connection request. The WTRU may continue Mode 2 transmission of D2D data until there is no D2D data in the WTRU D2D transmission buffer.

[0183] A WTRU may be configured with power control procedures that the WTRU may perform when changing the scheduling mode for D2D communications. The WTRU may be configured to determine a power control operation mode when the WTRU detects a change in the D2D operation mode. Methods and procedures related to power control may be applied when the WTRU changes its D2D operation mode when the WTRU changes coverage state. Methods and procedures related to power control may be applied when the WTRU changes its D2D operation mode when the WTRU changes its D2D operation mode.

[0184] The WTRU may be configured to use CLPC (e.g., with an indication signaled with the grant signal), for example, when using Mode 1. The WTRU may be configured to determine which power control mode to use when the WTRU moves to Mode 1. For example, the WTRU may be configured to autonomously use a closed-loop power control mode, for example, when the WTRU determines that it is operating in D2D communication Mode 1. The SIB may indicate semi-static power control parameters. The D2D grant may carry a dynamic closed-loop indication.

[0185] The WTRU may be configured to determine which power control mode to use when moving from Mode 1 to Mode 2. The WTRU may be configured to determine which power control mode to use, for example, when the WTRU moves out of Mode 1. The WTRU may be configured to read the SIB. The WTRU may be configured to determine the power control mode to use based on the SIB configuration (e.g., the WTRU may be configured to use open loop power control). The WTRU may be configured to use fixed power control autonomously, for example, if the WTRU fails to read the SIB.

[0186] The WTRU may be configured to select a resource pool for the WTRU to transmit (Tx) and / or receive (Rx). A D2D-enabled WTRU may be configured with at least a receive resource pool (e.g., or receive pool) and / or at least a transmit resource pool (e.g., or transmit pool). A D2D-enabled WTRU may be configured to use resource pools. The WTRU may be configured to determine a receive pool as an aggregation of resource pools from different receive synchronization sources / relays and a transmit pool from a resource pool received from a serving (e.g., or primary) synchronization source / relay. A transmit pool may refer to a transmit mode. A receive pool may refer to a receive mode. A transmit mode may refer to a transmit pool. A receive mode may refer to a receive pool.

[0187] The WTRU may be configured with a resource pool configuration. The resource pool configuration may include and / or be defined by one or more resource pool parameters. Example resource pool parameters that may be associated with or used to define a given resource pool may include one or more resource configurations (e.g., which may include one or more D2D reception and / or D2D transmission parameters). Example resource pool parameters may include one or more authorized application types, authorized usage areas, and / or index IDs. Example resource pool parameters may indicate whether a pool is available for control usage and / or whether a pool is available for data usage. Example resource pool parameters may include one or more activation or deactivation triggers, time windows, priorities, transmit powers, transmission control indications, traffic types, device types (e.g., D2D relays), and / or service types. For example, a D2D resource configuration may include one or more D2D reception parameters. The one or more D2D reception parameters may include or indicate a subset of time-frequency (T / F) resources to be monitored for receiving D2D signaling from other devices, such as when operating in Mode 1 and Mode 2. One or more D2D reception parameters may include or indicate a set of separate T / F resources for Mode 1 and Mode 2 and / or a subset of T / F resources to be listened to for D2D control messages (e.g., scheduling assignments or D2D synchronization messages). The D2D resource configuration may include one or more D2D transmission parameters. The D2D transmission parameters may include or indicate a subset of T / F resources to be used for D2D transmissions when operating in Mode 1 and Mode 2. The D2D transmission parameters may include or indicate a set of separate T / F resources for Mode 1 and Mode 2 and / or a subset of T / F resources to be used for transmission of D2D control messages. The D2D transmission parameters or D2D reception parameters may include one or more time domain modes.

[0188] Examples of resource pool parameters may include authorized application types. For example, the authorized application type resource pool parameter may include an indication of whether the pool is for commercial or public safety applications, or both. The authorized application type resource pool parameter may include an indication of whether the resource pool may be used for relaying, for example, by a relay WTRU or a remote WTRU using a relay service. The authorized application type resource pool parameter may include an indication of a group of applications or services for which the resources may be used. For example, a resource pool configuration may be used for a public safety fire department application. Examples of resource pool parameters may include authorized usage areas. For example, the authorized usage area may be an indication of the PLMN, eNB, cell ID, and / or tracking area ID with which the resources are authorized to be used. If the WTRU is under the coverage of a base station or eNB operating with one or more associated PLMNs, the WTRU may be configured to use the corresponding resource pool.

[0189] An example of a resource pool parameter may include an index ID. For example, the resource pool information may include an index ID that may identify a resource pool. The index ID may identify a resource pool via a resource configuration index. A resource pool may be characterized by an index ID. A base station or eNB may use the resource pool index to signal the resource pool that may be used by the WTRU.

[0190] The resource pool may be associated with control and / or data usage. For example, the resource pool information may include an indication of whether the resource pool is applied to D2D control messages (eg, synchronization messages over PD2DSCH), D2D data messages, or both.

[0191] A resource pool may be associated with an activation / deactivation trigger. If resources are pre-configured or semi-statically allocated, the resource pool may include indications that configure the WTRU to use the resources when desired and / or when the resources have been activated / deactivated. The base station or eNB may configure the WTRU using RRC signaling and may explicitly activate and / or deactivate the resource pool.

[0192] A resource pool can be associated with a time window. A resource pool configuration can indicate the duration during which a resource can be valid.

[0193] The WTRU may receive an indication that may indicate whether the WTRU may attempt (eg, always attempt) Mode 1 transmissions before using a Mode 2 transmission pool.

[0194] A resource pool may be associated with a priority. The priority may indicate a priority level. The WTRU may be configured to select a resource pool based on the priority.

[0195] A resource pool may be associated with transmission power and / or control information. A resource pool may be characterized by a maximum transmission power and / or transmission range. A WTRU may determine a transmission power based on the transmission power and / or control parameters (e.g., when using a resource pool for transmission).

[0196] Resource pools may be associated with traffic types. Traffic types may include unicast and / or broadcast / multicast. For example, a WTRU may route unicast traffic via a resource pool with a unicast traffic type. A resource pool with a unicast traffic type may be reserved so that non-unicast traffic may be blocked from that resource pool. As another example, a WTRU may route any type of traffic via a resource pool with a non-unicast traffic type. As another example, a WTRU may route broadcast and / or multicast traffic via a resource pool with a broadcast / multicast traffic type.

[0197] Resource pools can be associated with device and / or service types. Resource pools can be reserved for device types. Resource pools can also be reserved for service types. For example, a resource pool can be reserved for relay devices supporting relay services. Resource pools can be initialized / reinitialized independently by higher layers.

[0198] As described herein, each resource pool may be associated with an index. The WTRU may be configured with one or more resource pools. The WTRU may be configured with one or more resource pools via higher layer signaling (e.g., RRC). The one or more resource pools may be defined via a specification. The WTRU may determine one or more characteristics of the resource pool. The WTRU may look up resource pool information associated with the received resource pool index.

[0199] The WTRU may be configured to select a resource pool, for example, from a plurality of resource pools. The WTRU may be configured to select a resource pool for D2D Tx / Rx. The WTRU may be configured with separate pools to be used for reception and transmission of D2D communications. The WTRU may receive one or more reception and / or transmission resource pools from one or more sources. The WTRU may select a resource pool based on one or more resource pool selection criteria. The WTRU may receive multiple resource pool configurations, for example, based on resource pool selection criteria. The WTRU may select a resource pool configuration based on the application being run, or the group in which the WTRU is currently participating. If the WTRU is part of a fire department public safety group, it may be configured to first identify a resource pool dedicated to the fire department (for example, as defined by a configured group ID). The resource pool configuration may be aligned for a group between multiple synchronization sources. If the WTRU selects a resource pool from multiple synchronization sources, the WTRU may select a resource pool that is advertised to support the application or group in which the WTRU is participating or is a part of.

[0200] Based on the resource pool selection criteria, the WTRU may determine the receive pool as an aggregation of the resource pool from the same or different receive synchronization source / relay and the transmit pool from the resource pool received from the serving (eg, or primary) synchronization source / relay.

[0201] Based on the resource pool selection criteria, the WTRU may be configured to prioritize resource pools based on the source of the resource pool configuration. For example, the WTRU may prioritize the resource configuration obtained from the base station or eNB based on the resource configuration originating from other D2D WTRUs (e.g., other synchronization sources).

[0202] Based on the resource pool selection criteria, the WTRU may be configured to prioritize resource pools from the primary or serving synchronization source. The selection of the primary or serving synchronization source will be described in more detail below.

[0203] Based on the resource pool selection criteria, the WTRU may be configured to prioritize the latest resource pool information.

[0204] Based on the resource pool selection criteria, the WTRU may be configured to prioritize resource pool configurations from the highest priority source or from relay sources.

[0205] Based on the resource pool selection criteria, the WTRU may be configured with one or more of the priority rules described herein and their relative order. The WTRU may be configured to default to a common resource pool, for example, if a previously prioritized selection is unavailable. The WTRU may be configured to default to a random selection of a resource pool, for example, from a predefined set of resources.

[0206] A WTRU may be configured to select a resource pool associated with a relay service, for example, based on resource pool selection criteria. For example, a WTRU configured to function as a relay may be configured with one or more resource pools for relay transmission / reception. A WTRU configured as a remote WTRU using a relay service provided by a relay WTRU may be configured to select one or more resource pools associated with the relay service when transmitting data destined for the relay service.

[0207] A WTRU may be configured to forward (e.g., transmit) a selection of a resource pool to other WTRUs. The WTRU may determine to transmit information related to a resource pool to other WTRUs, as described herein. The WTRU may determine that a resource pool may be transmitted to other WTRUs when the WTRU is a synchronization source or a relay source.

[0208] A WTRU may be configured to become the source of D2D resource configuration when it becomes a synchronization source as described herein. A WTRU may be configured to determine a resource pool to transmit based on resource configuration detected from other sources. In a non-limiting example, an out-of-coverage WTRU may select its resource pool based on messages received from neighboring D2D WTRUs (e.g., based on synchronization messages received from neighboring WTRUs).

[0209] The WTRU may prioritize the resource pools used by its neighbors and select non-overlapping resource blocks or pools among the allowed pools, which are not advertised by other D2D WTRUs. If no such resource blocks are available, the WTRU may be further configured to select the resource pool associated with the synchronization message with the weakest signal.

[0210] The WTRU may be configured to align its resource pool with neighboring WTRUs or synchronization zones associated with the same group as the WTRU. A WTRU that is part of a fire department public safety application / group may align its resource pool with resource pool information detected from neighboring fire department group WTRUs.

[0211] The WTRU may be configured to select a resource pool randomly, for example, if no other rules are available.The resource pool may be selected from a predetermined set that may be transmitted within a synchronization message.

[0212] The WTRU may use a resource pool identified by the eNB (e.g., when the WTRU is in coverage). For example, the network (e.g., eNB) may configure the WTRU with a resource pool index. As another example, the network may configure the WTRU with a set of resource pool parameters.

[0213] The WTRU may determine that a resource pool is to be transmitted for other WTRUs, for example, when the WTRU is forwarding information from other synchronization sources.

[0214] The WTRU may transmit the resource pool assignment and resource configuration as part of a synchronization message or a relay message. The resource configuration may include a set of parameters and / or a resource configuration index.

[0215] A WTRU may be individually configured with a resource pool configuration that will be forwarded as part of the synchronization message. A WTRU in coverage may be configured with in-band resources for its own D2D communication. A WTRU in coverage may use a pre-configured out-of-band resource pool that will be conveyed in the synchronization message.

[0216] The WTRU may be configured to forward a subset of resources to be forwarded as part of a synchronization message.

[0217] The WTRU may be configured to evaluate / re-evaluate the D2D Rx / Tx resources based on triggers. The WTRU may be configured to evaluate and / or re-evaluate the set of D2D Rx / Tx resources based on one or more of the following triggers. The WTRU may be configured to evaluate and / or re-evaluate the set of D2D Rx / Tx resources based on one or more of the triggering events described herein.

[0218] The WTRU may trigger an evaluation and / or re-evaluation of resources to be used for D2D Rx / Tx (eg, Mode 1 or Mode 2) based on one or more triggering events described herein.

[0219] The WTRU may be configured with rules for selecting resources based on the current D2D coverage status.

[0220] The WTRU may be configured with rules for selecting resources based on a change in the operational mode to be used to acquire D2D resources (eg, based on a change between Mode 1 and Mode 2, eg, based on a change from Mode 1 to Mode 2).

[0221] If one or more D2D resources are used, the WTRU may be configured with rules for selecting a resource pool based on the RRC state.The WTRU may be configured to use resources signaled by one or more base stations or eNBs (e.g., signaled via one or more SIBs) when the WTRU is in RRC_IDLE mode.

[0222] When new data arrives at the access stratum (AS) from a D2D application, the receipt of the new data may trigger the AS to determine (eg, look up) D2D resources and if no resources are available, the WTRU may be triggered to take steps to acquire D2D resources.

[0223] The WTRU may receive signaling from higher layers indicating that a new D2D service is configured.

[0224] The WTRU may be configured to select resources, for example, when the WTRU is configured to operate as a relay WTRU.

[0225] A WTRU may be configured to select resources, for example, when the WTRU is configured to act as a remote WTRU. A remote WTRU may refer to a WTRU that can use relay services from a relay WTRU.

[0226] If D2D resources are used and the WTRU is operating in Mode 1, the WTRU may be configured to first attempt to request resources from the network. If resources are not available within the configured duration, the WTRU may be configured to fall back to a semi-static or pre-configured resource pool (e.g., using Mode 2).

[0227] An RRC_IDLE or RRC_CONNECTED WTRU camped on an appropriate serving cell may be configured to initiate D2D resource selection using Mode 1. In such a scenario when new D2D data arrives, the WTRU may initiate a request to obtain resources from the base station or eNB. If the procedure is unsuccessful (e.g., if there is no response to the scheduling or RRC connection request within a preconfigured duration), the WTRU may attempt to use a resource pool configured using broadcast signaling. If no resources are available in the broadcast, or the WTRU cannot decode the SIB, the WTRU may transition to a preconfigured resource pool.

[0228] If D2D resources are used, the WTRU may be configured with rules for selecting a mode and resource pool based on the RRC state. In a non-limiting example, the WTRU may be configured to operate in Mode 2 when it is in RRC_Idle mode. This rule may take precedence over the mode defined by the base station or eNB.

[0229] The change in the selected D2D resources may also trigger the WTRU to perform one or more additional D2D steps.The update of the selected resources may also trigger the WTRU to transmit the new resource configuration to other neighboring WTRUs.

[0230] A WTRU may be configured with a time-domain D2D transmission / reception mode. A D2D WTRU may perform D2D transmission / reception according to a D2D mode (e.g., transmission / reception may be allowed at certain times / subframes and may be blocked at other times / subframes). A D2D mode may define reception timings for the WTRU (e.g., times when the WTRU expects to receive from a selected resource pool). A D2D mode may define transmission timings (e.g., times when the WTRU may transmit). A D2D mode may define reception timings for the WTRU as well as transmission timings (e.g., a time mode indicates times during which a D2D WTRU may perform D2D transmission and / or reception). A WTRU may be configured with one or more modes associated with a priority. The WTRU may be configured with rules for selecting a mode to be used based on the priority of the data to be transmitted or received. For example, mode 1 may be associated with high priority data, mode 2 may be associated with medium priority data, and so on. The WTRU may be configured with rules for selecting a mode based on the role of the WTRU. For example, the WTRU may select a given mode when the WTRU is operating as a relay. A transmission mode may refer to a transmission pool. A reception mode may refer to a reception pool. A transmission pool may refer to a transmission mode. A reception pool may refer to a reception mode. As described herein, the D2D mode and the transmission pool may be used interchangeably.

[0231] The WTRU may be configured to use the D2D mode when the WTRU is in normal UL communication with a base station or eNB and the WTRU determines to perform D2D communication (e.g., in another spectrum, or in the same spectrum but when restricted to a single receiver). The WTRU may be restricted to a single receiver when it must tune out of the eNB to receive data. The WTRU may use the D2D mode when the WTRU desires to perform communications on a different frequency or when it desires to allow some form of battery saving when the WTRU is operating in out of coverage mode and performing D2D communication. The triggers for starting to use this mode are described below.

[0232] When a WTRU is out of coverage, it may wish to continue receiving in the resources using the resource pool.The WTRU may be configured to use a DRX-like approach.

[0233] The WTRU may be configured to determine when to use a mode (e.g., a pool) based on a detected trigger. The WTRU may receive an explicit indication to use a transmission mode (e.g., a transmission pool) or a reception mode (e.g., a reception pool) based on one or more criteria. For example, when a synchronization message (e.g., a synchronization message of a selected synchronization source or relay) includes the mode, and / or the WTRU may explicitly receive the mode from a base station, eNB, or from another controlling entity. When the WTRU receives the explicit indication, the WTRU may initiate use of the mode and / or associated pool. For example, when the WTRU is configured to operate as a relay, the WTRU may begin initiating use of the mode. The WTRU may be configured to operate as a relay when the WTRU receives an indication to begin operating as a relay. The WTRU may receive a request or mode transmission from an entity (e.g., another WTRU) that may be allowed to communicate with the WTRU (e.g., the group ID corresponds to at least one allowed / configured group ID of the receiving WTRU). The WTRU may receive an explicit indication that it may initiate use of the transmission mode or reception mode when a D2D discovery or communication session is initiated. When a WTRU is configured to operate as a relay WTRU or when a WTRU is configured to communicate with a relay WTRU, the WTRU may be configured in different ways.

[0234] A WTRU may be configured to determine when to transmit or communicate a mode of use to one or more other WTRUs based on a trigger. The WTRU may determine the modes it may use and potentially initiate transmission of at least a transmission mode indication or a reception mode indication as part of its synchronization message. The WTRU's initiation of transmission of the mode indication and / or determination of the mode to be used for transmission may be based on a trigger described below (e.g., a trigger to determine becoming a synchronization source or relay). The WTRU's initiation of transmission of the mode indication and / or determination of the mode to be used for transmission may be based on one or more additional triggers. The one or more triggers may include a time-based resource usage trigger, an operating frequency trigger, a trigger based on the WTRU's state, a trigger based on hopping of the reception mode, a trigger indicating that the WTRU may be configured with an energy-saving mode of operation, and a trigger indicating that the WTRU detects a mode. When the WTRU is operating as a relay node, the WTRU may transmit one or more selected modes. A WTRU operating as a relay may initiate transmission of one or more modes based on a change in the WTRU's role (e.g., operating as a relay node) or based on a change in the data / services supported by the WTRU (e.g., when the WTRU begins forwarding a new MBMS service).

[0235] When the WTRU determines that a second WTRU is using a different time pattern than the first WTRU, the first WTRU may receive an indication of a time pattern / resource usage trigger. The WTRU may determine to align the pattern or request a new pattern, for example, as described herein. The WTRU may also determine to transmit a pattern indication in a synchronization message. When the WTRU may be connected for communication on a frequency other than the operating frequency of the second detected WTRU, the WTRU may receive an indication of an operating frequency trigger. The WTRU may request the pattern, initiate the use of the pattern, or may transmit the pattern indication in a synchronization message. A WTRU that may receive a pattern to use may also determine whether to transmit (e.g., send) a pattern indication in a synchronization message, for example, if the WTRU determines to communicate with the WTRU on another frequency. The WTRU may receive an indication of a trigger based on the WTRU's state. For example, if the WTRU is in coverage, the WTRU may use the pattern provided by the eNB, and if the above criteria are met, the WTRU may transmit the pattern indication. If the WTRU is out of coverage and receives a pattern indication, in some examples, the WTRU may use it to determine transmission timing and / or reception timing, but may not further forward or relay the pattern indication in its own synchronization message.

[0236] The WTRU may receive an indication of a trigger based on a hop count of a received mode (e.g., based on a detected hop count). When the receiving WTRU receives the mode indication, the receiving WTRU may use the mode indication to determine whether to forward the mode indication in a synchronization message. The WTRU's determination to forward may depend on the hop count or the source from which the synchronization message may be received. In some examples, if the WTRU has already received the mode from a synchronization source (e.g., from a base station or eNB), the WTRU may transmit the mode indication in its synchronization message. If the WTRU receives the mode indication from a transmitting relay with a hop count greater than the configured hop count, the WTRU may determine not to further transmit the mode indication in its synchronization message.

[0237] A WTRU may detect a trigger that indicates that the WTRU may be configured for an energy-saving mode of operation. Upon detecting the trigger, the WTRU may use the mode indication and further transmit the mode indication in a synchronization message that the WTRU may receive during a configured time mode, for example, if the WTRU is configured for an energy-saving mode of operation. A trigger that indicates that the WTRU detects (e.g., uses or transmits) a mode (e.g., a certain type of mode) may occur when the WTRU determines that it may become a synchronization source or relay or may communicate to another WTRU and initiates the transmission and use of the mode indication on a synchronization message. The trigger for operating as a synchronization source may be different from the trigger for operating as a relay. One or more triggers described herein may be used by the WTRU to determine that the WTRU may operate as a synchronization source, a relay, or both.

[0238] For example, the WTRU may determine whether to become the synchronization source based on the measured signal strength of the source (e.g., eNB) being less than a predetermined threshold. The WTRU may become the synchronization source, for example, if the WTRU is in coverage or connected to a base station or eNB and detects a synchronization message (e.g., D2DSS or control message) from a lower priority source or from a source that is not a base station or eNB (e.g., the second WTRU is out of the WTRU's range). In another example embodiment, the WTRU may initiate this step if the WTRU determines that the second WTRU belongs to an allowed group of the WTRU.

[0239] For example, an in-coverage WTRU that determines to communicate with an out-of-coverage WTRU may coordinate and communicate receive / transmit pools through control or synchronization messages to enable communication.

[0240] A WTRU may determine whether a neighboring WTRU is in-coverage or out-of-coverage based on detected D2D control signals or messages (e.g., D2DSS or PD2DSCH). For example, a first WTRU (e.g., an in-coverage WTRU) may detect a second WTRU and determine that it corresponds to an out-of-coverage WTRU based on one or more attributes or the identity of a received D2DSS.

[0241] A WTRU may determine to operate as a relay, or the WTRU may determine to provide relay services, for example, based on one or more of the following example situations. The WTRU may determine to operate as a relay when the WTRU detects that another out-of-coverage WTRU is requesting relay services (e.g., an out-of-coverage WTRU may request a relay WTRU to provide services that the WTRU may be configured to provide as a relay service). The WTRU may determine to operate as a relay when the WTRU is connected (e.g., via a series of control message exchanges) to one or more remote WTRUs. The WTRU may determine to operate as a relay when the WTRU determines that the WTRU has relay data to transmit and / or to the network. The WTRU may determine to operate as a relay when the WTRU determines that the WTRU has relay data to receive (e.g., when the WTRU may be connected to at least one remote WTRU). The WTRU may determine to operate as a relay when the WTRU receives an explicit command from the network to operate as a relay, or when the WTRU is configured by higher layers to operate as a relay. The WTRU may determine to operate as a relay based on signal strength measurements with the eNB and / or other out-of-coverage WTRUs, etc.

[0242] Upon determining that the WTRU is acting as a synchronization source or relay, the WTRU may initiate the transmission of one or more indications, for example, on a synchronization message. The WTRU may indicate to the network when it is acting as a relay and the allocated resources are insufficient to support all remote UEs.

[0243] When a first WTRU detects that a trigger or combination of triggers described herein is satisfied, the WTRU may initiate transmission of a synchronization message (e.g., PD2DSCH) or a control message including a transmission and / or reception mode / pool indication. The content of the synchronization message may be determined based on the role being performed by the WTRU. For example, when the first WTRU detects a trigger to become a relay, the synchronization message content may include one or more resource mode / pool indications.

[0244] A WTRU may receive a message (e.g., a control message, a synchronization message, or a PD2DSCH) that may include content of a mode / resource pool. The synchronization message, the control message, and the PD2DSCH may be equivalent. The mode included in the synchronization message (e.g., the PD2DSCH) may correspond to one or a combination of the following. The mode in the synchronization message may correspond to a transmission pool. A WTRU receiving a synchronization message may use the transmission pool to determine one or more transmission opportunities. One or more transmission opportunities may be for D2D transmissions (e.g., all D2D transmissions) or one or more transmission opportunities may correspond to transmission opportunities for services that are allowed to be received by the WTRU that is transmitting the synchronization message (e.g., based on an identity transmitted on the PD2DSCH, or based on higher layer signaling). Transmissions performed by other WTRUs (e.g., a WTRU out of coverage) may be received by a WTRU in coverage. The transmission pool indication to be transmitted on the PD2DSCH or on another control message may be determined by the WTRU based on an explicit configuration received by the network (e.g., a transmission pool configuration sent on the PD2DSCH or in another control message). The transmission pool indication to be transmitted on the PD2DSCH may directly correspond to the pool that the WTRU in coverage is using in the current cell (eg, the reception pool received by the eNB).

[0245] The manner indicated in the synchronization message may correspond to a reception pool. A WTRU receiving the synchronization message may use the reception pool to determine at least a subset of reception opportunities. The reception pool indication to be transmitted on the PD2DSCH may be determined and may correspond to an explicit configuration received by the network (e.g., a reception pool configuration sent on the PD2DSCH). If the WTRU is configured with a Mode 2 configuration, the reception pool indication to be transmitted on the PD2DSCH may directly correspond to the pool that the WTRU in coverage is using in the current cell (e.g., the transmission pool received by the eNB). The manner in the synchronization message may correspond to that provided in the following example embodiments.

[0246] The WTRU may explicitly request the network to allow the WTRU to initiate the transmission of a mode or resource pool indication. When the first WTRU detects that one or a combination of the above triggers are met, the first WTRU may send a request or message to the eNB to report the detection of one or a combination of the triggers (e.g., a detected out-of-coverage WTRU, a detected out-of-coverage WTRU requesting relay service, a WTRU determining that it is acting as a relay (e.g., configured by a higher layer to become a relay), or a trigger that the WTRU becomes a synchronization source from the eNB). The WTRU may include one or more of the following in the request message: information about the trigger for the message, including, for example, one or more of the cause, measurement, WTRU identity, etc. The WTRU may include information about the relay-related service request in the request message, including, for example, the identity of the remote WTRU requesting the relay service, the service type, QoS, etc. The first WTRU may initiate the transmission of the mode indication or resource pool via PD2DSCH or other control message based on the confirmation and configuration from the network. The first WTRU may indicate one or a combination of the following information to the network. The first WTRU may indicate the reason for the request (e.g., a detected out-of-coverage WTRU or the first WTRU has received a request for relay service), the identity of the detected WTRU, the group ID to which the detected WTRU belongs, the ProSe ID, and the number of WTRUs requesting service. The first WTRU may indicate the unique identifier of the detected WTRU, the detected D2DSS of the WTRU that triggered the report, the recommended resource pool or mode, and the operating frequency of the detected WTRU. The first WTRU may indicate a request to initiate service as a relay. The first WTRU may request to stop transmission of the PD2DSCH (e.g., an out-of-coverage WTRU is no longer detected or the trigger to become a synchronization source is no longer met, or the relay service is no longer required).

[0247] The WTRU may wait for an explicit indication (e.g., a message) from the eNB or primary synchronization source to perform one or more of the following. The WTRU may initiate transmission of one or more resource pool indications (e.g., start transmitting synchronization messages and / or signals). The WTRU may receive resource pool information that the WTRU may be configured to transmit. The WTRU may be configured with resources (e.g., PD2DSCH and SA resources) where synchronization messages and / or signals may be transmitted and are periodic. The WTRU may include additional information in the synchronization messages and / or signals. The WTRU may wait for a request from an in-coverage WTRU to provide the WTRU identity of an out-of-coverage WTRU when available.

[0248] Upon receiving a synchronization message indication from the eNB, the WTRU may initiate or may configure the transmission of a synchronization message, which may include one or more resource pools or mode indications.

[0249] If the WTRU identity of the detected WTRU (e.g., the WTRU is out of coverage) that triggers the initiation of the synchronization message is initially unknown, the WTRU may continue monitoring until it is able to detect the identity of the detected WTRU. The WTRU may report the identity of the detected WTRU to the network when available.

[0250] The network may use the identity of the detected WTRU to determine whether the covered WTRU should start, continue, or stop transmitting synchronization messages (e.g., if the corresponding WTRUs cannot communicate with each other or do not belong to the same group or service, or if the corresponding WTRU is authorized for such service). The network may also use the identity of the detected WTRU or the D2DSS to determine whether any other covered WTRUs are transmitting the same resource pool to enable communication with the detected WTRU. The network may determine to stop PD2DSCH transmission of at least one of the other covered WTRUs that are performing PD2DSCH transmission.

[0251] The WTRU may determine (e.g., independently) whether the WTRU can communicate with the detected WTRU based on the determined identity and may implicitly stop. If the WTRU detects at least one WTRU in the vicinity of which it has not determined the identity or with which it can communicate, the WTRU may continue to transmit.

[0252] The WTRU may determine to stop transmission of synchronization messages (e.g., when out of coverage signals are no longer detected). The WTRU may stop transmission and indicate to the network that the WTRU stops transmitting synchronization messages. The WTRU may indicate to the network that no out of coverage D2D signals are anymore detected and that the WTRU may wait for an explicit instruction to start or stop. The WTRU may indicate to the network that there are no more remote WTRUs using relay services or that the WTRU will not be configured to provide relay services (e.g., when it is determined that the WTRU is not requested to provide relay services). The WTRU may wait for an explicit instruction to start or stop transmission of PD2DSCH or control messages. The WTRU may autonomously determine to stop transmission of PD2DSCH or control messages.

[0253] Upon receiving a pattern or determining that the WTRU must use a pattern, the WTRU may perform one or more of the following operations. The WTRU may restrict all transmission opportunities to fall within a given pattern. This may ensure that a WTRU that is relaying or transmitting a message may be able to receive the message. Another operation may include restricting all reception opportunities in a given resource pool to a given pattern. The reception opportunities may be an aggregation of different resource pools or patterns of reception. This operation may be advantageous in that it may improve battery life. Depending on the coverage state, one or more operations of the WTRU may be different. For example, a WTRU that is in coverage may use a pattern to perform reception in a given resource pool. Depending on the mode that the WTRU is using (e.g., mode 1 or mode 2), the WTRU may perform transmissions during some of those opportunities (e.g., in mode 2) or rely on the actual transmission opportunities dynamically scheduled by the eNB (e.g., mode 1). A WTRU that is out of coverage may use a pattern to determine available transmission opportunities, for example, as described herein. A WTRU that is out of coverage may always receive, for example, to ensure proper reception of data from all other WTRUs. An out-of-coverage WTRU configured for power saving may receive during aggregation in a configured manner or in a differently configured manner (eg, if multiple sources are present).

[0254] Based on the received pattern, the WTRU may determine the transmission time opportunities (e.g., TTIs) that the WTRU may use for transmission and / or reception. For example, if the pattern includes a duration (e.g., a number of consecutive TTIs), a cycle, and / or a subframe number, the WTRU may determine the time instances (system frame number (SFN) and subframes) during which the WTRU may be allowed to receive transmissions / receptions.

[0255] In order to align with the transmission pattern, the SFN or reference time that the receiving WTRU (eg, an in-coverage WTRU or an out-of-coverage WTRU) may be using may be provided in the synchronization message along with the pattern.

[0256] The pattern may be a bitmap or a fixed pattern associated with subframes within a frame or multiple frames. The reference frame may be a specific frame that may be specifically defined within the synchronization channel.

[0257] The WTRU may detect different modes. The WTRU may be connected to a selected synchronization source or relay, however it may be able to receive and decode synchronization messages from multiple sources. The WTRU may determine that the modes used from different synchronization sources may be different. This may cause the WTRU connected to different synchronization sources to potentially not be able to receive data from other clusters. To avoid data loss, the WTRU may report this discrepancy to the cluster head, detect the discrepancy in becoming a synchronization source, and send the same mode. The WTRU may trigger the initiation of a synchronization message and indicate that the message is being transmitted to align the modes. The WTRU may transmit the mode of the highest priority detected source or relay. The WTRU may determine the transmission timings for the two detected modes and transmit the message twice in the two transmission timings. The WTRU may limit transmissions to transmission timings that overlap between different received modes (e.g., if there is no overlap, the WTRU may perform one of the actions described above).

[0258] The WTRU may receive the mode explicitly. For example, the WTRU may receive the mode via dedicated signaling or a broadcast message that may be broadcast from a base station or eNB. The mode may be included in a synchronization message received from a synchronization source or synchronization relay. The WTRU may receive the mode from another WTRU via a dedicated message. The WTRU may receive the mode from a pre-configured WTRU (e.g., the WTRU may be configured with a set of modes from which it can select).

[0259] The WTRU may determine the mode to be used and transmit using the determined mode. The WTRU may determine the mode to be used based on the WTRU's capabilities and the D2D services configured from one or more higher layers. For example, if the WTRU includes a single receiver, the WTRU may determine the mode to be used for the WTRU to receive from both the DL and D2D links to TDM. For example, to avoid self-interference, a mode may be used for TDM between the WTRU to Uu Tx and D2D Tx / Rx.

[0260] The WTRU may be configured to determine (e.g., select) the mode to be used based on the type of traffic being transmitted and / or received. For example, when relaying such traffic, the relay WTRU may be configured to use a transmission mode used for relayed traffic. The remote WTRU may be configured to use a resource pool or mode associated with the relay when transmitting or receiving data to / from the relay, and to use another mode or resource pool when transmitting other data (e.g., non-relayed D2D transmissions). For example, the selection of the mode may be based on the priority associated with the received mode and / or the priority of the data or service determined by the WTRU. The priority of the WTRU service or data may be determined based on several factors including user priority, static priority configured in the WTRU, priority of the application originating the data, or the highest priority of one or more applications of the service, data, etc. running in the originating WTRU.

[0261] The WTRU may determine the number of transmission subframes that may be used in one or more discovery opportunities, for example, based on the number of discovery sessions initiated. The WTRU may select a transmission subframe based on one or more of the following factors. The WTRU may use the number of discovery sessions initiated by higher layers to select a transmission subframe. The WTRU may select a transmission subframe based on the ratio of the number of sessions in which the WTRU is announcing the WTRU to the number of sessions in which the WTRU is monitoring the WTRU. The WTRU may select a transmission subframe from a list of configured modes (e.g., even subframe mode or odd subframe mode). The WTRU may select a transmission subframe based on the D2D-RNTI.

[0262] The WTRU may send an indication using a determined mode. The WTRU may be configured to send an indication when it determines the mode. The WTRU sends the indication to an eNB, a synchronization source, or another WTRU. The indication may include one or more of the following. The indication may include a mode selected by the WTRU. The indication may indicate the subframe in which the WTRU is configured to perform D2D Tx and / or D2D Rx. The indication may indicate when the WTRU is configured to start using the mode, for example, the information may be indicated using a subframe index and / or SFN index when D2D tx / rx may be performed. The indication may include a duration during which the WTRU may use the mode. The indication may indicate when the WTRU is configured to stop using the mode.

[0263] The WTRU may be configured to detect a trigger that indicates when to send an indication regarding the use of a determined mode. The WTRU may be configured to send an indication in the following circumstances. The indication may be sent based on an explicit command by the eNB (e.g., the eNB may send a message requesting the WTRU to send the mode). The indication may be sent when a D2D discovery or communication session is started or stopped by one or more higher layers. The indication may be sent when the WTRU is about to perform a service that may require a change in mode (e.g., a new service).

[0264] The WTRU may be configured to perform a synchronization step, for example, using a synchronization principle. To simplify signal detection and demodulation, one or more example embodiments provide a predefined frame structure for D2D communications. The predefined frame structure may be used and defined by all D2D WTRUs. The frame structure may be defined such that the location (e.g., in time and / or frequency) of one or more of a scheduling assignment (SA), a D2D synchronization signal (D2DSS), a physical D2D synchronization channel (PD2DSCH) (e.g., a broadcast control channel for D2D), a discovery signal, and a data transmission may be easily determined (e.g., known). An example D2D synchronization frame structure may be provided in FIG. Figure 5(time domain) and Figure 6 (time-frequency-domain).

[0265] The WTRU may be configured to use multiple frame formats for D2D synchronization frames. The WTRU may be configured with multiple frame formats. The frame formats may define various locations of various elements of D2D communication. Some non-limiting examples may include D2DSS, PD2DSCH, Scheduled Addressing (SA) area, Discovery area, D2D data, or the like.

[0266] Different frame formats can be configured so that D2DSS positions (e.g., in time) do not overlap between different formats. This can allow multiple D2DSS hops to have the same format. This example embodiment can be used in Figure 7 Similar concepts can be applied in the time-frequency domain in a designed frame format configured to allow D2DSS locations (eg, in time and frequency) to not overlap between different formats.

[0267] The WTRU may determine to use a fixed format. For example, the WTRU may be configured to use a fixed format based on a specification. In a non-limiting example, the format may depend on the frequency band, WTRU category or other fixed standard. The WTRU may determine the frame format to use based on a pre-configuration in which the WTRU may be pre-configured, for example, by the network or via its USIM, or other internal configuration with the D2D synchronization frame format to be used. The WTRU may be configured with a specific D2D synchronization frame format to use, for example, when the WTRU becomes the synchronization source. The WTRU may determine the frame format to use based on an implicit format in which the WTRU may be configured to determine the frame format being received, for example, based on synchronization signal characteristics and / or PD2DSCH (for example, content and / or source location). The WTRU may determine the frame format to use based on an explicit format in which the WTRU may be configured to determine the frame format based on explicit signaling, for example, from the PD2DSCH.

[0268] The WTRU may determine frame timing based on a frame format and D2DSS characteristics. The WTRU may be configured to determine frame timing and synchronize to an associated D2D synchronization frame. A D2D synchronization frame format may be determined, wherein the WTRU may determine the D2D synchronization frame format and then determine a time position of the D2D synchronization frame. D2DSS characteristics may be determined, wherein the WTRU may determine the D2D synchronization frame based on the D2DSS characteristics. The D2DSS characteristics may include the timing of D2DSS reception. A synchronization signal hop count and / or information received from the PD2DSCH may be used to determine frame timing and synchronize to an associated D2D synchronization frame.

[0269] WTRUs in the same synchronization area may have the same synchronization frame. To facilitate communication between WTRUs in the same vicinity, WTRUs in the same vicinity may share the same D2D synchronization. Some WTRUs may relay D2DSS up to a maximum number of hops. The number of hops as described above can exceed two hops, for example, Figure 4 As shown in the synchronization protocol in . A synchronization source (SS) can be a device that transmits a D2DSS with an independent synchronization reference. The SS can be a network source (e.g., a base station or eNB) in which case it can be called a network SS (NSS). The SS can be an unconnected independent source (e.g., a WTRU) in which case it can be called an independent SS (ISS). A relayed synchronization source (RSS) can be a device that can transmit a D2DSS but can obtain a synchronization reference from another source such as an ISS or NSS. An RSS can use another RSS as a synchronization reference up to a maximum hop count. The area where all WTRUs synchronize to the same SS can be called a synchronization zone (SZ).

[0270] The WTRU may be configured to receive an indication of the hop count and synchronization source identity from the D2DSS. The synchronization frame for the RSS may be configured to be identical to the synchronization frame from its associated SS. In order for WTRUs in the same synchronization zone to have the same synchronization frame, the synchronization frame for the RSS may need to be identical to the synchronization frame from its associated SS.

[0271] The WTRU may determine the synchronization frame and hop count from the D2DSS. The WTRU may derive the synchronization frame timing from the received D2DSS timing and / or from the associated hop count. The relayed D2DSS may carry an indication to ensure that the WTRU can obtain the synchronization frame timing from the synchronization source (e.g., so that the WTRU does not track the same multiple synchronization areas).

[0272] Since the synchronization frame timing may be associated with the synchronization source, the WTRU may identify the synchronization source from the D2DSS, eg, whereby the receiving WTRU may be able to detect the presence of multiple synchronization sources / frame timings.

[0273] The D2DSS may carry information about one or more of a synchronization source ID, a synchronization source type (eg, a source connected to a base station, an eNB, or an independent source), and / or a hop count.

[0274] The WTRU D2DSS signal may be based on a known Zadoff-Chu signal, a known predefined length, a predefined bandwidth (e.g., number of PRBs), and a duration (e.g., number of OFDM symbols, which can be, for example, 1 OFDM symbol). The D2DSS may be transmitted multiple times during a D2D synchronization frame, or even multiple times during a subframe. Similarly, the D2DSS may be augmented by a second synchronization signal (e.g., S-D2DSS), which may be used to carry additional implicit information.

[0275] A D2D WTRU may be configured with more than one set of ZC root sequences for a D2DSS. Each set of ZC root sequences may be associated with a synchronization source type. For example, a D2D may be configured with 2 ZC root sets, each set may include one or more ZC root sequences and the ZC roots from each set may be different. The first set may correspond to sources associated with an eNB or network. The second set of ZC roots may correspond to sources associated with an independent synchronization source. A D2D WTRU configured as a relay synchronization source may be configured to use ZC roots from the same set as the synchronization it may be relaying. When the WTRU becomes its own synchronization source, it may be configured to select a ZC root for its D2DSS from a specific set, for example, from a set associated with an independent synchronization source.

[0276] A secondary D2DSS may be used, for example, to improve synchronization. The sequence used for the secondary D2DSS (S-D2DSS) may be used to further indicate the source identity. The S-D2DSS may be composed of another ZC sequence or an m-sequence. The set of allowable sequences may be indexed. The set of allowable sequences may be associated with at least a portion of the synchronization source identity. Reference Figure 8 , the description of the example synchronization source ID is shown according to the example implementation. Figure 8 As illustrated in , a complete synchronization source identity may consist of an aggregation of primary D2DSSs (P-D2DSSs), eg, by aggregation type, type ID index, and S-D2DSSs.

[0277] The D2DSS may carry (e.g., implicitly carry) a hop count. The hop count may be indicated by the S-D2DSS index. For example, a small number of bits from the S-D2DSS index may be used to indicate the hop count. The cyclic shift associated with the D2DSS may be used to indicate the hop count. A symbol pair carrying the D2DSS may be used to carry hop count information. For example, the cyclic shift difference between two D2DSS symbols may indicate the hop count.

[0278] Other combinations based on the techniques described above can be used to implicitly carry the synchronization source.

[0279] The WTRU may be configured to select or reselect a synchronization source. Since there may be a limited number of hop counts and since the WTRU may be close to the eNB, the WTRU may be able to acquire synchronization from multiple synchronization sources (e.g., NSS, ISS, or RSS). The WTRU may prioritize the synchronization sources, for example, to determine the synchronization frame to use for data reception / transmission.

[0280] The WTRU may be configured with prioritization rules. The synchronization source may include an eNB. The synchronization source may include the WTRU. Rules for prioritizing ISSs may be used by the WTRU. If the WTRU detects D2DSSs from multiple ISSs, the WTRU may prioritize the ISSs based on the measured signal strengths of the received D2DSSs and the D2DSS with the higher signal strength may be prioritized.

[0281] The WTRU may be configured with rules to prioritize RSSs. If the WTRU detects a D2DSS from multiple RSSs, the WTRU may prioritize the RSSs based on the hop count values indicated by the D2DSSs. The RSS with the smallest hop count value may be prioritized.

[0282] The WTRU may be configured with rules to prioritize WTRUs connected to the network and the ISS. The WTRU may prioritize synchronization sources that are WTRUs in coverage of the network that relay D2DSSs from eNBs and ISSs that may be out of coverage. The prioritization rules may be based on several aspects. For example, the WTRU may be communicating with a WTRU that is connected to the network. In such a case, prioritizing these synchronization sources may be beneficial to the WTRU if the signal strength of the D2DSSs from the synchronization sources that are WTRUs connected to the network is greater than a predefined threshold. The WTRU may prioritize the ISS if the measured strength of the D2DSS is significantly stronger than that from the synchronization source connected to the network (for example, the measured energy level of the D2DSS from the ISS is X dB greater than the D2DSS from the synchronization source connected to the network, and X may be predefined).

[0283] The WTRU may be configured to maintain a prioritized list. The WTRU may be configured to maintain a prioritized list of synchronization sources detected by the WTRU. The WTRU may be configured to maintain a prioritized list, for example, based on one or more of the following triggers (e.g., in any order and / or combination). The WTRU may use situations / triggers to perform prioritization / reselection.

[0284] The WTRU may perform prioritization of synchronization sources periodically (e.g., the WTRU may perform prioritization after a certain amount of time has expired). The amount of time may be explicitly configured by the network or it may be pre-configured at the WTRU. The WTRU may perform prioritization of synchronization sources aperiodically (e.g., not periodically). Aperiodic prioritization may include detection of new sources. The WTRU may perform an update of the prioritization list upon detection of a new synchronization source. Detection of a new synchronization source may be declared when the measured energy of a D2DSS from a new SS (e.g., identified from a D2DSS) is detected to be greater than a certain threshold for a given period of time. A timeout triggered by a given source may be used, whereby the WTRU may perform prioritization when a given synchronization source times out and stops transmitting a D2DSS.

[0285] A hop count change may be used as a trigger. For example, the WTRU may perform prioritization when it detects a hop count change (eg, the identity of the SSs from the D2DSS is the same, but the associated hop count changes).

[0286] The absence of certain data in the buffer can be used as a trigger. The WTRU may perform prioritization when the WTRU determines that no data has been transmitted for a certain period of time and there is new data to be transmitted in the buffer. The WTRU may perform prioritization when it has no data or has D2D data to transmit for a certain period of time and there is new UL data to be transmitted.

[0287] The WTRU may use other variations / measurements. The WTRU may measure the energy level of the D2DSS of the current SS which may occur continuously or within a specified time period. If the measured signal strength is below a predefined threshold, the WTRU may perform prioritization and / or the WTRU may determine to become the synchronization source.

[0288] The WTRU may perform an update of the prioritized list when the measured energy level of the D2DSS from SSs other than the current SS changes. An example may be when the measured energy level of the D2DSS from other SSs increases above a predefined threshold or becomes greater than the energy level of the D2DSS of the current SS.

[0289] The measured energy level may be weighted (eg, divided in the dB domain, subtracted in the dB domain, or otherwise modified) by a thermal noise measurement / estimation performed by the WTRU.

[0290] The WTRU may apply prioritization. The WTRU may apply the new timing at a specific synchronization frame time point (e.g., the WTRU may apply the new timing not at the current synchronization frame, but at the beginning of the next synchronization frame). Given that there may be a timing difference between the old and new synchronization timing references, the gap between synchronization frames may accommodate such a difference.

[0291] The WTRU may be configured not to update the prioritized list when one or more of the following triggers are met: The WTRU may not update the prioritized list when it is transmitting or receiving data. The WTRU may not update the prioritized list when the WTRU is within a timer-to-trigger period.

[0292]

[0014] The WTRU may be configured to prioritize synchronization regions for data reception. Due to practical hardware considerations, a WTRU may not be able to track an unlimited number of synchronization regions simultaneously. A practical WTRU may be able to decode a limited number of scheduling announcements (SAs) in a subframe.

[0015] The WTRU may be configured to prioritize synchronization regions for data reception.

[0016] The WTRU may be configured to prioritize synchronization regions for data reception based on one or more prioritization information.

[0293] The synchronization ID associated with the synchronization source may be prioritization information used by the WTRU to prioritize synchronization regions for data reception.The WTRU may be configured to determine the synchronization source ID and determine whether to prioritize the synchronization source ID, for example, based on predefined rules / configuration.

[0294] The synchronization type associated with a synchronization source may be prioritization information used by the WTRU to prioritize synchronization regions for data reception. The WTRU may be configured to determine the synchronization type and prioritize based on the type. The WTRU may be configured to prioritize data reception sources that are connected to the base station, eNB, or via an independent source (e.g., an independent source may have a lower priority).

[0295] The group ID associated with a synchronization area may be prioritization information used by the WTRU to prioritize synchronization areas for data reception. The WTRU may determine the group ID associated with the synchronization area by decoding the PD2DSCH. The group ID may be in the detected SA associated with the synchronization area. The WTRU may prioritize synchronization areas. One or more group IDs associated with the WTRU may be configured for synchronization areas and / or supporting synchronization areas.

[0296] The WTRU hardware capabilities may be prioritization information that the WTRU uses to configure the priority of synchronization regions for data reception. The WTRU may prioritize when the number of sources is greater than the number that the WTRU can decode within a set time / delay.

[0297] The WTRU reception / transmission mode may be prioritization information used by the WTRU to configure the priority of synchronization areas for data reception. Due to its reception / transmission mode, the WTRU may not be able to receive data from another synchronization area. In this case, the synchronization area may not be prioritized.

[0298] A WTRU may be configured to transmit a synchronization signal (D2DSS). A D2D WTRU may be configured to transmit a synchronization signal. Methods related to transmission of a synchronization signal (eg, D2DSS) are described below.

[0299] The WTRU may be configured to determine frame synchronization timing. The D2D WTRU may be configured to transmit a synchronization signal (e.g., D2DSS) and become a synchronization source. In this case, the WTRU may be configured to determine its own synchronization frame timing. The WTRU may be configured to determine the D2D synchronization frame using one or more of the following:

[0300] The WTRU may determine the D2D synchronization frame based on internal timing.The WTRU may determine the D2D synchronization frame timing arbitrarily, for example, based on the WTRU's internal clock.

[0301] The WTRU may determine the D2D synchronization frame based on external timing. The WTRU transmitting the D2D synchronization frame may be in the vicinity of other devices transmitting synchronization signals (e.g., other D2D WTRUs, network synchronization sources such as eNBs, etc.). In this case, if the WTRU is configured as a synchronization source, the WTRU may be configured to base its synchronization on the D2D synchronization frame based on these signals. This configuration may provide the benefit of aligning adjacent D2D synchronization areas, for example, to mitigate interference.

[0302] The WTRU may align its D2D synchronization frame with another received D2D synchronization frame.The WTRU may align its D2D synchronization frame with a received reference D2D synchronization frame (eg, the D2D synchronization frame corresponding to the highest priority D2DSS).

[0303] The WTRUs may align their D2D synchronization frames so that the control channel region covered is reduced. This configuration may provide the benefit of mitigating interference between control channels.

[0304] The frame format may be based on the WTRU ID. When a D2D WTRU becomes the synchronization source, the D2D WTRU may be configured to determine the initial value of the D2D synchronization frame number (D-SFN) or the D2D synchronization frame counter. The WTRU may be configured to initialize the D-SFN value based on the WTRU identifier (e.g., IMSI, D2D-related ID, RNTI, or similar). This configuration may provide the benefit of randomizing the D-SFN and potentially associated frequency-time resource configurations between adjacent synchronization areas.

[0305] A WTRU may be configured to transmit a preamble and / or a postamble. A WTRU monitoring a D2D data transmission may receive data from multiple synchronization areas. A receiving WTRU in this case may obtain the associated synchronization frame for the transmission. A D2D transmitting WTRU (e.g., a WTRU transmitting D2D data) may be configured to transmit a D2DSS when transmitting data communications, for example, in order not to limit the range of the D2D communication.

[0306] The WTRU may transmit a synchronization preamble before sending data. The D2D transmitting WTRU may be configured to transmit a synchronization preamble before transmitting the actual data. The WTRU may be configured to transmit the D2DSS or other information (e.g., PD2DSCH) during a preconfigured time period before starting to transmit data, e.g., Figure 9 shown.

[0307] The WTRU may transmit a synchronization postamble after transmitting data. The WTRU may be configured to transmit the D2DSS within a predetermined period of time after transmitting its last data packet. This configuration may have the benefit of ensuring that the WTRU does not stop transmitting the synchronization signal, for example, if more data arrives in the buffer and if the WTRU synchronization signal is being relayed by other WTRUs.

[0308] The WTRU may be configured to start an inactivity timer when the latest data packet has been transmitted. The WTRU may reset the timer when new data is being transmitted. When the timer expires, the WTRU may be configured to stop transmission of synchronization signals.

[0309] The WTRU may determine when to initiate transmission of a synchronization signal or message.The WTRU may trigger transmission of a synchronization message and / or signal (eg, as a source or as a forwarding / coordinating WTRU) based on one or more of the following triggers.

[0310] The WTRU may detect triggers based on explicit indications from the network. The triggers may be received by the WTRU from the eNB / ProSe function / application to start / stop operating in PS mode or by explicit configuration by the base station or eNB to detect any of the triggers described herein.

[0311] The WTRU may detect a trigger based on the detection of one or more other synchronization signals. The WTRU may detect another WTRU transmitting a synchronization signal originating from a source with a lower priority than the WTRU's serving synchronization source. A WTRU connected to an eNB (e.g., in coverage) may determine to begin transmitting synchronization signals or messages when it detects a synchronization message or signal from an out-of-coverage WTRU. This may allow the out-of-coverage WTRU to find an in-coverage WTRU and synchronize to the receive / transmit opportunity of that WTRU.

[0312] The WTRU may detect another WTRU transmitting a synchronization signal originating from a source having a lower priority than the WTRU's serving synchronization source, and at least one of the second WTRU's group IDs belongs to the same group ID as the first WTRU.

[0313] A WTRU may be an in-coverage WTRU and may detect a synchronization signal of an out-of-coverage WTRU or an out-of-coverage WTRU.

[0314] The WTRU may use a group ID, where at least one of the one or more communication group IDs of the second WTRU belongs to at least one of the one or more group IDs of the first WTRU.

[0315] The WTRU may receive data from a second WTRU and determine that the WTRU is not in coverage of the base station or eNB. This may use some indication in the SA that the WTRU is not in coverage, for example, if there is no D2DSS or message.

[0316] The WTRU may use a timer based on the absence of other synchronization signals. The timer from the most recent synchronization signal reception may have expired. If the WTRU does not receive a synchronization signal or message from the source, the WTRU may determine to change to the source signal.

[0317] The WTRU may determine to become the synchronization source, for example, based on the measured strength falling below a threshold.

[0318] If the following is detected (eg, as described herein), the WTRU may determine to initiate transmission of a synchronization signal.

[0319] The WTRU may use a time scheme / source. A first WTRU may determine that a second WTRU is using a different time scheme than the first WTRU.

[0320] The WTRU may be configured to detect an operating frequency difference, whereby a first WTRU may be connected for communication at a frequency other than the operating frequency of the second WTRU.

[0321] The WTRU may determine when to stop and / or change the transmission of synchronization signals and / or messages. The WTRU may stop and / or change the transmission of synchronization signals when one or more of the following triggers (e.g., situations) are met. The trigger may be an explicit configuration from the network (e.g., the network explicitly configures the WTRU to stop transmitting). Based on a timer trigger, the WTRU may stop the transmission of synchronization signals after a configured time period. The trigger may be based on data activity, which may include an indication that the WTRU has not performed data transmission within the configured time period. The trigger may be based on an indication that an application process is no longer requesting service. The trigger may be based on an indication that the WTRU has not detected any data activity from any neighboring WTRU (e.g., no SA is detected). The detection of another synchronization signal, wherein the detection of another synchronization signal from a higher priority source or another WTRU may trigger the WTRU to stop the transmission of its current synchronization signal and / or modify the transmitted synchronization messages and / or signals.

[0322] The WTRU may stop and / or determine changes that may be performed, for example, based on the transmission of a synchronization signal. The WTRU may stop and / or determine changes that may be performed, for example, if one or a combination of the following conditions are met. The WTRU may stop and / or determine changes that may be performed, for example, if the WTRU detects a synchronization signal from a higher priority source (for example, the source is a base station or eNB). The metric may include the received synchronization signal power being above or below a configured threshold. The WTRU may stop and / or determine changes that may be performed, for example, if the WTRU detects a synchronization signal from a second WTRU. The WTRU may determine that the synchronization signal from the second WTRU has the same source and has a hop count that is lower than its current hop count. The metric may include the received synchronization signal power being above or below a configured threshold.

[0323] The WTRU may stop and / or determine changes that may be performed, for example, if the WTRU detects a synchronization signal from a source of the same priority and the hop count is lower than the current WTRU hop count. The metric may include the received synchronization signal power being above or below a configured threshold. In response to determining that the re-evaluated hop count has reached a maximum allowed value (e.g., or is higher than the maximum allowed value), the WTRU may stop and / or determine changes that may be performed. If the detected WTRU is connected to a base station or eNB (e.g., based on a synchronization signal or SA), the WTRU may stop and / or determine changes that may be performed. If the detected WTRU belongs to the same group as the first WTRU (e.g., based on a synchronization signal or SA), the WTRU may stop and / or determine changes that may be performed.

[0324] The WTRU may stop transmission of the D2DSS, for example, if one or more of the following criteria are met. In response to determining that the synchronization timer has expired or is not running, the WTRU may stop transmission of the D2DSS. The WTRU may start the synchronization timer when one or more of the following conditions are met. The WTRU may start the synchronization timer when the WTRU becomes the synchronization source and initiates synchronization signal / message transmission. The WTRU may start the synchronization timer when the WTRU becomes the synchronization source based on other detected synchronization signals (e.g., as described herein). The WTRU may start the synchronization timer when the timer is restarted, for example, when the WTRU receives data or detects a scheduling assignment between transmissions (e.g., there may be other WTRUs connected to the cluster). The WTRU may start the synchronization timer based on data activity, for example, as described herein. The WTRU may start the synchronization timer based on determining that no other WTRU is relaying the synchronization message being transmitted by the WTRU, for example, as determined based on measuring a D2DSS with the same source ID but with a higher hop count.

[0325] If one or more of the criteria for stopping transmission of synchronization messages are met, but the synchronization timer is running, the WTRU may determine to modify the synchronization signals and messages that the WTRU is transmitting. This may be used, for example, to reflect or relay at least part of a detected higher priority synchronization message.

[0326] The WTRU may stop transmission of the synchronization signal when the WTRU determines that the WTRU will stop being a synchronization source and / or determines that a synchronization signal change has been triggered. The WTRU may determine that it is no longer needed to be a synchronization source when a measurement exceeds a predetermined threshold.

[0327] In response to determining that no other WTRU is relaying the WTRU's synchronization message, the WTRU may determine whether other WTRUs are relaying its message by performing one or more of the following: The WTRU may detect a D2DSS signal with the same source ID but a higher hop count and determine whether an associated synchronization message exists. The WTRU may detect a synchronization message carrying the same content, possibly indicating a higher hop count, and / or detect a synchronization message by detecting a synchronization message with the same source ID.

[0328] The WTRU may receive synchronization channel messages. A synchronization source and / or synchronization forwarding entity may transmit synchronization messages. The synchronization information may be sent explicitly as a message, or the information may be obtained implicitly from synchronization reference signal characteristics.

[0329] For example, the synchronization message may be sent over a D2D data channel (e.g., a communication channel). The synchronization message may be transmitted by the WTRU using a communication MAC PDU. An indication in the MAC header may be included, for example, to allow a receiving WTRU to identify the message as a control message. The WTRU may decode the message and / or use the contents of the message. Control messages (e.g., RRC, SIB, and / or the like) may be transmitted on the MAC PDU. A logical channel value reserved for control messages may indicate to the receiving WTRU that this is a control message.

[0330] The WTRU may use PD2DSCH transmission formats and characteristics. The PD2DSCH may be associated with a special synchronization signal. In order for a receiving WTRU to be able to determine the PD2DSCH associated with a received D2DSS, the WTRU may use one or more of the following.

[0331] The PD2DSCH may be transmitted in the same frequency resources as the D2DSS. Once the D2D synchronization frame is obtained, the WTRU may unambiguously retrieve the PD2DSCH. This example embodiment may not be too difficult to implement, but may not be robust enough to combat interference from other PD2DSCHs or data transmitted in the same set of T / F resources.

[0332] The PD2DSCH scrambling sequence may be based on the synchronization source ID. The WTRU may be configured to use a scrambling sequence associated with the D2DSS (e.g., synchronization area ID, group ID, etc.) used for the PD2DSCH. The synchronization source ID may be used to index a specific scrambling sequence used for the PD2DSCH. This example embodiment may provide the benefit of whitening interference and may reduce the likelihood of neighbor synchronization sources using the same synchronization source ID.

[0333] The SA may indicate the PD2DSCH resource using a specific identifier linked to the synchronization source ID. The T / F positions for the PD2DSCH may not be predefined but may be conveyed using a scheduling assignment (SA), for example, similar to D2D data transmission. The WTRU may be configured to use one or more specific values in the SA (e.g., a specific destination group ID) to ensure that other WTRUs can properly decode the PD2DSCH. The contents of the SA (e.g., source ID) may be associated with the D2DSS or synchronization source to allow the receiving WTRU to associate the PD2DSCH with the appropriate synchronization source or frame.

[0334] The PD2DSCH may be explicitly indicated based on the logical channel ID in the MAC header. The WTRU may receive the PD2DSCH via a normal D2D communication channel. The WTRU may decode the channel based on the SA destination ID or source ID decoding. The WTRU may determine that the communication is a D2D synchronization message, for example, based on the MAC header (e.g., via a specific logical channel ID or other explicit MAC indication).

[0335] The WTRU may detect, select, or receive an indication of a PD2DSCH format. The WTRU may be configured to transmit the PD2DSCH in more than one physical layer format. For example, the physical layer format may include one or more PRBs, one or more OFDM symbols, a coding scheme, a coding rate, puncturing, a CRC, and / or the like. The physical layer format may support different payload sizes (e.g., depending on the content). Different payload sizes in the PD2DSCH may support a PD2DSCH that may carry more (e.g., or less) information based on the coverage state of the WTRU. The coverage state of the WTRU may include being in coverage, out of coverage, and / or the like.

[0336] The WTRU may determine the PD2DSCH format to be used. For example, a WTRU transmitting a PD2DSCH may be configured to determine the PD2DSCH format based on the size of the payload. The WTRU may be configured with a set (e.g., a fixed set) of PD2DSCH formats that support corresponding payloads (e.g., a fixed set payload). The WTRU may select a format (e.g., to maintain an appropriate decoding rate). The WTRU may determine the content of the PD2DSCH payload based on the coverage status. The WTRU may be configured to select a PD2DSCH format based on the coverage status. For example, the WTRU may select a first PD2DSCH format when the WTRU is in coverage. As another example, the WTRU may select a second PD2DSCH format when the WTRU is out of coverage.

[0337] The WTRU may determine the PD2DSCH based on the associated D2DSS signal. The WTRU transmitting the PD2DSCH may be configured to select one or more parameters of the associated D2DSS. The one or more selected parameters may indicate the PD2DSCH format. For example, the WTRU may be configured to select the primary synchronization signal (PSS) portion of the D2DSS to indicate that the source is out of coverage and / or indicate (e.g., implicitly indicate) the PD2DSCH format. The WTRU monitoring the PD2DSCH may be configured to determine the format of the PD2DSCH based on the D2DSS signal associated with the PD2DSCH. For example, the WTRU may determine one or more characteristics of the D2DSS (e.g., the Zadoff-Chu root of a signal associated with the PSS such as the D2DSS). The WTRU may determine the format of the associated PD2DSCH via predefined association rules. For example, the WTRU may be configured to determine whether the WTRU transmitting the D2DSS is in coverage or out of coverage (e.g., out of network coverage). The WTRU may determine (e.g., implicitly determine) the format of the associated PD2DSCH based on the coverage state of the transmitting WTRU.

[0338] The WTRU may transmit the PD2DSCH using different resources when retransmitting with different hop counts. When the WTRU retransmits or relays the PD2DSCH with different hop counts (for example, in the same synchronization area), the WTRU may be configured to use different time-frequency resources to mitigate interference. The WTRU may be configured to transmit the PD2DSCH at a specific time position, which may depend on the hop count. The WTRU may transmit the PD2DSCH in a specific D2D synchronization frame number associated with the hop count. The WTRU may be configured to transmit the PD2DSCH at a specific frequency position, which may depend on the hop count. The WTRU may transmit the PD2DSCH in a specific frequency offset associated with the hop count. The WTRU may be configured to transmit the PD2DSCH using a predefined time-frequency manner, which may depend on the hop count.

[0339] The WTRU may determine the content of the synchronization message. The synchronization message may include one or more of the following content information. The synchronization message may include a resource pool, which indicates that the WTRU may be provided with a receiving pool and / or a transmitting pool. The WTRU may be configured to use a resource pool. The WTRU may determine the receiving pool as an aggregation of resource pools from different received synchronization sources / relays and a transmitting pool from a resource pool received from a serving synchronization source / relay. The synchronization message may include a resource pool index (e.g., a resource pool configuration index).

[0340] The synchronization message may include a subset of one or more resources within a resource pool or a D2D mode that can be used by the receiving WTRU for D2D transmission and / or D2D scheduling assignment. The message may include a suggested time mode (e.g., recurring, duration, or the like), a frequency that the remote WTRU may use for D2D transmission. The suggested time mode may include a time mode received from a base station or eNB (e.g., or another source entity). The suggested time mode may be determined autonomously in the coordinating WTRU based on information available to the WTRU. For example, the coordinating WTRU may determine the suggested time mode based on the service being supported by the WTRU. For example, for a single receiver WTRU, the coordinating WTRU may be receiving an MBMS transmission, and the coordinating WTRU may determine the suggested time mode to allow the WTRU to receive on the MBMS subframes configured by the eNB.

[0341] The resources may include an index (e.g., multiple indices) that describes one or more resources (e.g., in time / frequency) within a resource pool that the remote WTRU can use. The synchronization message may include a source identifier, which may include the identity of the source node where the resource configuration is occurring. The identity may include one or more of the following: a BS ID, an eNB ID, a cell ID, a PCI number, a PLMN of the cell, a WTRU-specific ID, a ProSe ID, a ProSe group ID, a ProSe application ID, and / or an indication of whether the source is a base station or an eNB, or another type of source (e.g., another WTRU or a cluster header). The synchronization message may include a WTRU identifier that is used to identify the WTRU performing the transmission. The identity may include one or more of the following: a BS ID, an eNB ID, a cell ID, a PLMN of the cell, a WTRU-specific ID, a ProSe ID, a ProSe group ID, a ProSe application ID.

[0342] The synchronization message may include location information. The location information may be associated with a WTRU in coverage. A WTRU (e.g., transmitting and / or receiving) may determine its location based on, for example, a cell ID, GPS information, or other location information and append the location information to the control message. The synchronization message may include a hop count indicating the number of hops from the source node or an indication of whether the transmitting entity is the source entity. The synchronization message may include a time reference number and / or a frame number (e.g., a SFN number) used as a reference for synchronizing reception and / or transmission methods.

[0343] The synchronization message may include an indication that the WTRU is within the coverage of a base station or eNB. The synchronization message may include a data relay and an associated ID indicating whether the WTRU is a data relay. Further configuration related to the relay network may be indicated, such as the set of supported APNs or network IDs. The synchronization message may include, depending on the scenario, the latest link status, which may indicate that the WTRU can transmit a value for the link status of a characterized channel or its link to the previous hop or to the synchronization source / network. This value may be based on a measurement. The measurement value may be the average RSRP over a specific time period or an error rate.

[0344] The synchronization message may depend on the scenario including the aggregated link condition, where the WTRU may transmit a value that characterizes the link condition of the aggregated channel or all links to the synchronization source / network. This value may be based on measurements, such as RSRP averaged over a specific time period. This value may represent an error rate. The WTRU may determine this value by adding the condition transmitted on the previous hop PD2DSCH to the condition measured by the WTRU for the previous hop.

[0345] The synchronization message may include a scheduling period. The WTRU may transmit during the scheduling period.

[0346] The WTRU may be configured to detect situations where PD2DSCH is transmitted. The WTRU may transmit PD2DSCH when the WTRU becomes an independent synchronization source and transmits D2DSS. The WTRU may transmit PD2DSCH when the WTRU relays synchronization from another source. The WTRU may transmit PD2DSCH when the WTRU determines that it must transmit in a certain manner (for example, the WTRU has restricted transmission / reception opportunities). The WTRU may transmit PD2DSCH when the WTRU is in coverage and has been triggered to become a synchronization signal / message transmitter.

[0347] The WTRU may use rules to determine the content of the PD2DSCH.When transmitting the PD2DSCH, the WTRU may be configured with a set of predefined values for one or more parameters carried on the PD2DSCH, and the WTRU may be further configured to determine the values of the one or more parameters.

[0348] The WTRU may determine the resource pool, for example, as described herein. The WTRU may transmit the resource pool configuration in the PD2DSCH.

[0349] The WTRU may determine the transmission and / or reception mode to be used to communicate with it. This configuration may be useful to ensure that the WTRU can operate as a relay and / or ensure that the WTRU can maintain a connection with the base station or eNB or another synchronization area. The WTRU may determine the transmission and / or reception mode to be used and transmit the configuration on the PD2DSCH. The new mode may be determined, for example, from a set of allowed predefined modes (e.g., indexed in the specification).

[0350] The WTRU may determine (e.g., autonomously) a mode based on one or more of the following: The WTRU may select a mode based on the modes it has configured to communicate with the network, for example, the WTRU may select a mode that maximizes the WTRU's opportunity to communicate with a base station or eNB. The WTRU may select a mode based on neighbor synchronization areas. For example, the WTRU may determine modes in neighbor areas and determine a mode to use that minimizes interference with neighboring synchronization areas. In idle mode and when in coverage, the WTRU may select a mode that does not overlap with its paging opportunities.

[0351] The WTRU may be configured to extend the PD2DSCH content. The PD2DSCH may be configured to carry information (e.g., a small amount of information), such as a subset of the information elements described herein. The PD2DSCH may be configured with a fixed, known, physical transport format. The WTRU transmitting the PD2DSCH may be configured to broadcast control information, such as to indicate additional information related to radio resource management, support for relaying, configuration information, measurement information, and the like. The PD2DSCH may be configured to carry a larger amount of information. The larger amount of information may vary in size. The WTRU may be configured to extend the content of the PD2DSCH.

[0352] like Figure 10 As shown, the PD2DSCH may include a scheduling assignment (e.g., a specific form of scheduling assignment). The PD2DSCH may include a format of the scheduling assignment (e.g., a specific format of the scheduling assignment). The PD2DSCH carrying the scheduling assignment may be referred to herein as a PD2DSCH-SA. For example, the PD2DSCH-SA may be transmitted using the same rules as a regular SA. For example, the PD2DSCH-SA may carry additional information in addition to a normal SA, for example, the PD2DSCH-SA may carry one or more of the following elements: a resource pool, a resource subset, a source identifier, a WTRU identifier, location information, a hop count, an SFN number or a time reference number, an indication that the WTRU is in coverage, a data relay, the latest link status, and / or an aggregated link status.

[0353] The scheduling assignment component of the PD2DSCH-SA may carry additional information. The data associated with the PD2DSCH may carry additional PD2DSCH elements or other information. Figure 10 , the PD2DSCH-SA may carry the PD2DSCH portion and the SA portion which may point to additional PD2DSCH-related data. Examples of regular SAs and data associated with regular SAs are given in Figure 10 Shown in.

[0354] The receiving WTRU may be configured to distinguish between a regular SA and a PD2DSCH-SA. The receiving WTRU may distinguish between a regular SA and a PD2DSCH-SA based on one or more of the following methods. The receiving WTRU may distinguish between a regular SA and a PD2DSCH-SA based on an identifier. An identifier (e.g., a specific identifier, e.g., PD2DSCH-SA-ID) may be associated with a PD2DSCH-SA (e.g., replacing a legacy target identifier carried in the SA) and may be used to distinguish a PD2DSCH-SA from a normal SA. Upon receiving the identifier (PD2DSCH-SA-ID), the receiving WTRU may determine that the received SA is a PD2DSCH-SA carrying PD2DSCH-related information. The receiving WTRU may interpret the received bits based on the PD2DSCH-SA content. The transmitting UE may be configured to transmit a PD2DSCH-SA with an appropriately configured identifier.

[0355] The receiving WTRU may distinguish between a regular SA and a PD2DSCH-SA based on a format or CRC check. The receiving WTRU may be configured to blindly distinguish between a PD2DSCH-SA and a legacy SA based on the CRC and format of the received signal. For example, if the CRC of the channel decoder is checked, the receiving WTRU may be configured to attempt reception of both SA and PD2DSCH-SA and determine whether the received signal is a regular SA or a PD2DSCH-SA. The receiving WTRU may distinguish between a regular SA and a PD2DSCH-SA based on the resources on which the signal is received. The receiving WTRU may be configured to distinguish between a PD2DSCH-SA and a legacy SA based on the resources on which the signal is received (e.g., time, frequency, or a combination of time / frequency). The WTRU may be configured with a set of resources that may be reserved for transmission of a PD2DSCH-SA. When receiving a signal on these resources, the receiving WTRU may be configured to use the PD2DSCH-SA format decoding. The transmitting WTRU may transmit a PD2DSCH-SA on resources reserved for PD2DSCH-SA transmission. The resources used for PD2DSCH-SA transmission may be pre-defined (eg, in the specification, via semi-static configuration, or on the USIM / application).

[0356] When the receiving WTRU has determined that the received SA is a PD2DSCH-SA, the receiving WTRU may be configured to receive the associated payload data. The associated payload data may be indicated in the SA portion of the PD2DSCH-SA. The receiving WTRU may apply one or more PD2DSCH parameters received by the receiving WTRU. The transmitting WTRU may be configured to transmit an additional data payload associated with the PD2DSCH at an appropriate location on the time / frequency as indicated in the SA portion of the PD2DSCH-SA. For example, one or more transmission parameters for the PD2DSCH data payload may be from a subset or a different set from the traditional parameters used for data transmission. The additional payload may consist of a limited amount of data and may not require more than one transmission.

[0357] like Figure 11 As shown, the PD2DSCH may include (e.g., carry) a scheduling assignment. The PD2DSCH may be transmitted in one or more known, predetermined formats and may carry an SA. The SA carried in the PD2DSCH may include the same information as the traditional SA. The SA carried in the PD2DSCH may have a smaller payload. One or more fields in the traditional SA (e.g., target ID) may not be included in the SA carried in the PD2DSCH.

[0358] The receiving WTRU may be configured to receive the PD2DSCH and determine whether SA carried in the PD2DSCH is present. If SA carried in the PD2DSCH is present, the receiving WTRU may be configured to determine the location of the associated data, further decode the data, and interpret the information as additional PD2DSCH payload and / or data.

[0359] The D2D UE may be configured to determine whether additional PD2DSCH data will be transmitted. The D2D UE may determine the format of the PD2DSCH and / or the content of the SA within the PD2DSCH based on whether additional PD2DSCH information will be transmitted. The D2D UE may appropriately set the value of the SA within the PD2DSCH and may transmit additional data at the location indicated in the SA within the PD2DSCH.

[0360] The WTRU may use a PD2DSCH that is directed to or associated with an SA. The PD2DSCH may be directed to or associated with an SA. The PD2DSCH may be directed to or associated with an SA that is directed to additional data. The PD2DSCH associated with an SA may be determined based on the PD2DSCH time / frequency or another parameter. The SA location in time or frequency may be explicitly transmitted in the PD2DSCH. Other WTRUs may not be allowed to select the SA resource to which the PD2DSCH is directed or associated. The mode may be selected from a specific mode design with few transmissions or a control-only mode design.

[0361] The PD2DSCH may be associated with an SA pointing to data resources carrying additional PD2DSCH content. A scheme for associating the SA with the PD2DSCH may be described. The association between the SA and the PD2DSCH is implicit (e.g., based on one or more characteristics of the PD2DSCH). The transmitting PD2DSCH may determine one or more transmit SA resources based on one or more of the following: PD2DSCH timing, PD2DSCH physical resources (e.g., subframe, PRB index, etc.), PD2DSCH identifier, and / or associated D2DSS ID, physical resources, or timing. The receiving WTRU may determine one or more receive SA resources and / or parameters based on one or more of the following: PD2DSCH timing, PD2DSCH physical resources (e.g., subframe, PRB index, etc.), PD2DSCH identifier, and / or associated D2DSS ID, physical resources, or timing.

[0362] The WTRU may be configured to determine the frequency resources of the SA associated with the PD2DSCH by determining the frequency (e.g., PRB) index associated with the PD2DSCH. The WTRU may be configured to determine the frequency resources of the SA associated with the PD2DSCH by determining the frequency (e.g., PRB) index associated with the PD2DSCH and may apply a mapping function thereto. For example, Figure 12 As shown, the SA associated with the PD2DSCH may be transmitted in the same frequency resources in subsequent subframes reserved for SA transmission (eg, a 1-1 mapping function).

[0363] To avoid SA collisions, the transmitting WTRU may be configured to monitor the PD2DSCH and not transmit SA in one or more resources associated with the PD2DSCH.

[0364] like Figure 13 As shown, the receiving WTRU may be configured to determine the location of the SA associated with the PD2DSCH based on the explicit indication carried in the PD2DSCH. The explicit indication carried in the PD2DSCH may be referred to as the SA. 索引The PD2DSCH may carry an explicit indication that the receiving WTRU may use to determine the association with the PD2DSCH. The transmitting WTRU may be configured to select resources for transmitting the SA according to the same rules as a normal SA and may indicate the SA 索引 For example, the SA associated with the PD2DSCH may be transmitted in a subframe (eg, a specific subframe reserved for the SA associated with the control information).

[0365] SA 索引 The receiving WTRU may implicitly determine the subframe information based on the transmission time of the PD2DSCH. For example, the subframe information may be the next available SA transmission subframe or the next available SA transmission subframe after a time (e.g., a minimum time) after the reception of the PD2DSCH has been received (e.g., 2 ms).

[0366] SA 索引 Time information and frequency information may be carried for the receiving WTRU to determine resources (eg, accurate resources) for the SA.

[0367] The transmitting WTRU may be configured to select SA resources associated with the PD2DSCH from a reserved set of one or more SA resources.The reserved set of one or more SA resources may be reserved for transmission of control information.

[0368] The transmitting WTRU may be configured to monitor the PD2DSCH and determine one or more SA resources for SA transmission associated with the PD2DSCH. 索引 The information carried in the PD2DSCH can avoid selecting SA resources from a set of SA resources known to be used for SA transmission associated with PD2DSCH.

[0369] The WTRU may be configured to select a data time mode for PD2DSCH extension. The transmitting WTRU may be configured to select a transmission mode for transmission of extended payload associated with PD2DSCH or control data using a different mechanism than normal data. The transmitting WTRU may be configured to select one or more transmission parameters from a specific set. For example, the transmitting WTRU may be configured to use multiple (a specific number) HARQ transmissions and a reception mode reserved for transmission of information or control information with a high probability of requiring large coverage.

[0370] The WTRU may be configured to coordinate resource usage. Once the WTRU is configured with resources for discovery signal transmission, the WTRU may perform transmissions accordingly. If the WTRU is in eNB coverage, resource pools and / or dedicated resources may be pre-configured and / or dynamically configured by the network. If the WTRU is out of eNB coverage, the WTRU may obtain resource configuration from stored pre-configurations and / or from a coordination entity (e.g., cluster-head). The resources used by the transmitting and receiving entities may be coordinated, for example, if discovery / communication is supported when the WTRU is in the coverage of the same configuration entity and / or is associated with mutually coordinated configuration entities. For example, if discovery / communication is supported in an uncoordinated scenario, problems may arise when the WTRU performs transmissions and / or receptions in multiple domains simultaneously.

[0371] For resource allocation, the WTRU may be pre-configured with a pool of resources to transmit / receive when operating in out-of-coverage mode. Specifically, all WTRUs may also be pre-configured with resources to transmit and receive resource configuration information (e.g., to send control information messages, such as synchronization messages). The WTRU may also be configured by a control entity as to which resources in the resource pool to use.

[0372] Figure 14 FIG2 is a diagram showing examples for in-coverage, out-of-coverage, and partial-coverage D2D discovery and / or communication scenarios.

[0373] A WTRU in coverage may discover and / or be discovered by a neighboring WTRU that may be controlled by other uncoordinated control entities and / or may be operating in a different spectrum. Since the eNB may provide a resource pool for discovery in coverage, the WTRU may not be able to discover and / or be discovered by a neighboring WTRU, for example, if the neighboring WTRU is not monitoring the same resource pool. A WTRU in coverage may move (e.g., autonomously) to public safety (PS) spectrum and / or out of coverage spectrum to perform reception and / or transmission, however, this may result in data loss and / or paging reception loss, for example, without network coordination. A WTRU in coverage may be configured to coordinate between the eNB and the WTRU in coverage.

[0374] A WTRU in coverage may determine to perform communications with an out-of-coverage WTRU, to act as a WTRU-to-network relay for another WTRU, and / or to perform communications with a neighboring WTRU, where the neighboring WTRU may determine the set of resources to use by a control entity (e.g., a cluster head) that is pre-configured and / or may not be coordinated with the serving eNB. The resources and / or time used for transmission by the neighboring WTRU may correspond to subframes in which the WTRU in coverage may be performing normal cellular communications. The WTRU in coverage may coordinate with the eNB to request a time and / or resources in which it can communicate with the neighboring WTRU without negatively impacting the cellular connection with the eNB.

[0375] A WTRU may switch (e.g., autonomously) to transmit and / or receive on resources where a neighboring WTRU is expecting to receive and / or transmit. This may result in data loss, the WTRU no longer transmitting in the UL, and / or missed paging opportunities while in idle mode. To avoid data loss and / or paging loss, coordination between the eNB, in-coverage WTRUs, out-of-coverage WTRUs, and / or a controlling entity out-of-coverage WTRUs may be provided, for example, for WTRUs using a single transmit and / or receive. Coordination may involve coordination of the time manner in which such communication is expected to occur and / or coordination of the resources (e.g., frequency and / or time) in which such communication and / or discovery may occur.

[0376] This coordination may be intended to allow the controlling entity to align the resources being used by the WTRUs involved in the communication and / or be aware of scheduling constraints during these time periods.

[0377] The network and / or coordination entity may be made aware of resource allocation conflicts, for example, so that the network may reallocate resources and / or schedule WTRUs accordingly. For example, this may be performed for communications between different clusters that may be controlled by different entities. An eNB may refer to a cluster head and / or control entity in a group and / or cluster. An in-coverage WTRU may refer to a WTRU that is connected to a cluster head and / or control entity. A neighboring WTRU, a PS WTRU, and / or an out-of-coverage WTRU may refer to a WTRU that is configured to operate in direct communication. The resource pools and / or configurations for neighboring WTRUs, PS WTRUs, and / or out-of-coverage WTRUs may be controlled by an uncoordinated control entity that is different from the in-coverage WTRUs and / or resources for which they are pre-configured.

[0378] The methods described herein related to in-coverage and out-of-coverage may be applied to allow coordination between WTRUs or eNBs, etc., that may be controlled by different uncoordinated control entities.

[0379] A WTRU that is in coverage may coordinate, request one or more gaps, and / or request resources to communicate with a WTRU that is out of coverage. Figure 15 FIGURE 1 is an illustration of an example scenario for communications between an in-coverage WTRU and an out-of-coverage WTRU. The WTRU may be configured to perform interactions between the in-coverage WTRU and the out-of-coverage WTRU, for example, to negotiate resource allocation for a link (e.g., PC5) beyond the network. The WTRU may be configured to perform interactions between the in-coverage WTRU and the eNB, for example, to support resource reconfiguration and / or gap / pattern configuration. The examples described herein may be applicable to situations where an in-coverage WTRU performs direct public safety communications over public safety resources.

[0380] The WTRU may be configured to negotiate resource allocation for out-of-coverage links. The in-coverage WTRU may have a coordinated time and / or gap arrangement, for example, so that it can tune out of the cellular link without risking data loss. The out-of-coverage WTRU may know when and / or where to expect reception and / or transmission, for example, to ensure that interested parties can receive communications.

[0381] The communication method may refer to the time pattern (e.g., periodicity, cycle, duration, and / or the like) in which the WTRU may transmit and / or receive. The communication method may refer to the time pattern for reception and the time pattern for transmission. The communication method may include resource information, such as, for example, frequency, one or more subframes, one or more PRBs, and / or the like.

[0382] An out of coverage WTRU may determine and / or drive resource allocation. Figure 16 is an illustration of an example of signaling that may be used by an out of coverage WTRU to determine and / or drive resource allocation. Resource allocation may refer to the time, slot-wise, and / or time and / or frequency configuration for a PS link. For example, an out of coverage WTRU may provide and / or broadcast (e.g., in known pre-configured resources) the resource allocation configuration that it is configured to use and / or is currently using for communication. Resource allocation may be in the form of an SA, a broadcast synchronization message, a control message, and / or the like. Resource configuration may include the time and / or frequency manner in which the PS WTRU is expecting to transmit and / or receive.

[0383] If the WTRU determines that a WTRU in coverage exists, the WTRU may provide resource configuration. The WTRU may provide resource configuration periodically or all the time and / or before data transmission. The WTRU may provide resource configuration when it is desired that the WTRU operate in a different spectrum.

[0384] A WTRU (e.g., an in-coverage WTRU) may receive (e.g., from an out-of-coverage WTRU) a configuration and / or timing pattern. The WTRU may communicate the configuration information in a report to the eNB. The information communicated to the eNB may include a recommended gap pattern and / or frequency resources for the out-of-coverage WTRU, e.g., for the out-of-coverage WTRU to use for communication. The in-coverage WTRU may determine to send this information to the eNB, for example, if it determines that the out-of-coverage WTRU is a WTRU that belongs to the same group as the in-coverage WTRU (e.g., the WTRU is allowed to receive from the device). The eNB may reconfigure the resource pools it uses (e.g., for discovery and / or communication) and / or provide gaps and / or scheduled opportunities for the in-coverage WTRU to listen to the out-of-coverage link, e.g., based on the resources provided by the out-of-coverage WTRU. The eNB may provide the gap pattern. The eNB may approve the use of the recommended gap pattern.

[0385] The gap pattern may be converted and / or adjusted based on the timing used by the controlling entity, for example, if the timing and / or reference frame number used to determine scheduling opportunities is different between the in-coverage WTRU and the neighboring WTRU.

[0386] The WTRU may determine resource allocation and / or may be driven by the eNB and / or the WTRU in coverage. Figure 17 is an illustration of an example of signaling that may be used by an eNB and / or an in-coverage WTRU to determine and / or drive resource allocation. Resource usage allocation for an out of coverage link may be driven by the in-coverage WTRU and / or the eNB. For example, the out of coverage WTRU may transmit (e.g., broadcast) a resource allocation pool that it may use to select resources for operation and / or the in-coverage WTRU may be aware of the resource pool based on pre-configured information. For example, once an in-coverage WTRU detects an out of coverage WTRU, the in-coverage WTRU may determine the resource pool that a neighboring WTRU is using. The in-coverage WTRU may not receive this information from the out of coverage WTRU and / or may rely on the pre-configured resource pool that it has for PS. The network may be aware of the resource pool that is pre-configured for the PS WTRU.

[0387] A WTRU (e.g., a WTRU in coverage) may send a report to the eNB, for example, based on one or a combination of the triggers described herein (e.g., upon determining to communicate as a PS WTRU and / or to communicate with a neighboring or remote WTRU, or upon determining to operate as a relay). The content of the report may be as described herein, and may include a resource pool that a neighboring PS WTRU may be using, a recommended time pattern, a pre-configured time pattern, requested resources to operate as a relay, requested services (e.g., an MBMS service group requested by a remote WTRU), and the like.

[0388] For example, upon receiving the request, the eNB may determine scheduling opportunities and / or gaps to allocate to the covered WTRU for PS communication and / or discovery and / or may send a gap pattern and / or time pattern and / or resource configuration to the WTRU or approve the use of the requested time pattern.

[0389] In the case of idle mode operation, the covered WTRU can determine, for example, based on the discovery resource pool (e.g., time pattern and / or frequency) and / or paging opportunity allocated for the covered WTRU, a time pattern that can allow the covered WTRU to tune out the serving eNB and successfully perform communications with neighboring WTRUs.

[0390] A WTRU in coverage may be configured by the eNB with a reception time pattern for communicating with other WTRUs (eg, for in-coverage and / or out-of-coverage of the eNB) and / or the WTRU in coverage may have a pre-configured pattern.

[0391] A WTRU in coverage may send messages and / or reports to a neighboring WTRU, for example, based on a determined pattern (e.g., determined from the eNB and / or internally). The message may be transmitted to the WTRU as a broadcast message, as a synchronization message, and / or as a dedicated message and / or transmitted using a control message that may be received by WTRUs belonging to the same group. The message and / or report may indicate the resource allocation, time pattern, and / or frequency at which the WTRU in coverage may transmit and / or receive. The neighboring WTRU may relay and / or transmit (e.g., broadcast) the message and / or pattern to its control entity, which may, for example, approve and / or configure the neighboring WTRU with the requested pattern and / or may send a new proposed pattern.

[0392] For example, in addition to the intermittent and / or time-based approach, the eNB may provide the WTRU with a specific resource configuration (e.g., frequency and / or time, e.g., by specifying one or more subframes and / or one or more PRBs) at which the out-of-coverage WTRU may transmit and / or receive with the in-coverage WTRU, where, for example, the frequency may correspond to the in-coverage resource pool. The out-of-coverage WTRU may be a separate, independent out-of-coverage WTRU that may be attempting to connect to the network using the in-coverage WTRU as a WTRU-to-NW (network) relay. The out-of-coverage WTRU may be communicating with another in-coverage and / or out-of-coverage WTRU.

[0393] The WTRU may be configured to facilitate interaction between an in-coverage WTRU and an out-of-coverage WTRU. When a WTRU begins operating in relay and / or PS mode, the WTRU may send one or more D2D synchronization signals (D2DSS) and / or control messages (e.g., synchronization messages). The WTRU may announce in a control message that it is capable of operating as a relay and / or PS node. Neighboring WTRUs operating in the vicinity of the coordination entity that is looking for the coordination entity may monitor (e.g., periodically monitor) D2DSS control symbols and / or may detect WTRUs (e.g., in-coverage WTRUs, out-of-coverage WTRUs, relay WTRUs, and / or the like). The trigger for the WTRU to begin operating as a relay node may be based on pre-configuration, measurement-based, measurement-based, based on an explicit trigger from the network and / or from a ProSe server, and / or the like.

[0394] A WTRU in coverage may send resource pool information, get responses, send reports to the eNB and / or the like. A WTRU operating as a relay and / or triggered to operate as a PS node may operate in unsolicited mode. For example, a WTRU may announce itself as a relay and / or a PS node. A WTRU may send an announcement message with one or more ProSe parameters (e.g., ProSe WTRU id, security, ProSe group id, etc.) and / or its resource pools that may be used for links with out-of-coverage WTRUs and / or other PS nodes. The WTRU may operate as a cluster head and / or attach this information as part of a cluster configuration message, e.g., a synchronization message. This may be used by the WTRU to support open discovery. The control message may carry the resource configuration indicated by the eNB.

[0395] The out-of-coverage WTRU may send a response accepting the configuration parameters. The response message may indicate one or more (e.g., a subset) of the resources in the pool that are acceptable to the out-of-coverage WTRU. The relay and / or PS node WTRU may use this information to send a report to the eNB, for example, as described herein. The eNB may accept the configuration. The eNB may configure gaps and / or reconfigure resources for the relay WTRU and / or PS node to be able to operate with the out-of-coverage WTRU and / or PS node using the gaps.

[0396] A WTRU may use resources for relaying control messages (e.g., synchronization messages). A WTRU operating as a relay may request resources to relay control messages. A WTRU operating as a relay may use semi-statically allocated resources signaled by an eNB (e.g., using SIB signaling) to relay control messages. A WTRU operating as a relay may use pre-configured resources to relay control messages. Resources may be explicitly pre-configured for control messages and / or the WTRU may select (e.g., autonomously select) resources from a pool of resources to be used for relaying control messages.

[0397] A WTRU out of coverage may request resource pool information, obtain information, send reports to the eNB, and / or the like. A remote and / or PS node WTRU may send a request message requesting any neighboring WTRUs capable of operating in relay and / or PS mode. The remote WTRU may request a specific service in the request message (e.g., requesting forwarding of an MBMS service indicated using an MBMSTMGI). The WTRU may operate as a cluster head. The WTRU may include resource pools that it desires to use for transmission and / or reception and / or is using in a cluster configuration message, e.g., for synchronization messages. A WTRU (e.g., capable of operating in relay and / or PS mode and / or operating in the requested mode) may respond and / or detect the node by declaring itself as a relay and / or PS node. The response message may indicate parameters identifying itself as a ProSe node (e.g., ProSe WTRU id, ProSe group id, etc.), security configuration, and / or the like. The responding WTRU may, for example, request different resource pools based on capabilities and / or existing gap configuration.

[0398] The relay and / or PS node WTRU may send a report to the eNB with this information (e.g., as described herein), for example, once resource negotiation is determined. This mode may support target discovery. The eNB may accept the configuration and / or configure gaps for the relay WTRU and / or PS node and / or reconfigure resources to be able to operate with the out-of-coverage WTRU and / or PS node using the gaps.

[0399] A WTRU may be configured to coordinate communications from a coordinating WTRU. The WTRU may send a report. The WTRU may identify one or more (e.g., all) of the resources in the report. A reporting mechanism, a WTRU, and / or a WTRU-transmitted message may be used to allow coordination of resources and / or timing used by WTRUs within a cluster and / or different cell coverage controlled by a coordinating entity. The report may include resource allocations for out-of-coverage links to assist the controlling entity and / or transmitting entity in determining scheduling timing and / or resource allocations. Resource allocation information may include information relayed by neighboring WTRUs, transmitted, broadcast, and / or available (e.g., configured or pre-configured) in the coverage WTRU.

[0400] The report (e.g., which may include a format, trigger, time window, and / or the like) may be configured by the network (e.g., by a network node such as an eNB). The network node may configure one or more WTRUs to operate in a certain D2D communication mode. Receiving the report by the network may trigger an action.

[0401] The report may be transmitted to a coordination entity and / or may be transmitted in the form of a broadcast message, as part of a synchronization message, as a dedicated message to the coordinating (eg, in-coverage) WTRU, and / or the like.

[0402] The report and / or WTRU-triggered transmission message may include resource configuration from a neighboring WTRU. For example, the report may indicate resource pool information obtained from a neighboring entity (e.g., a WTRU, a cluster head and / or an eNB, and / or an out-of-coverage WTRU).

[0403] The reported configuration may include a set of resources intended for D2D discovery (e.g., frequency, bandwidth, one or more subframes, one or more PRBs, time, and / or the like), a set of resources intended for D2D communication (e.g., frequency, bandwidth, one or more subframes, one or more PRBs, time, and / or the like), and / or the identity of the coordination entity and / or the identity of the WTRU providing the configuration information (e.g., cluster head id, eNB id and / or WTRU id, group ID, Prose ID and / or the like).

[0404] The WTRU-triggered report may include resources within the resource pool (e.g., a subset of resources) or a resource pattern that the in-coverage WTRU has requested from the eNB (e.g., or may use as previously received from the eNB and / or configured in the WTRU), e.g., so that it can communicate with the out-of-coverage WTRU. For example, the report may include a suggested and / or used time pattern (e.g., recurring, duration, etc.), frequency, and / or the like. The report may indicate a controlling entity that may be considered and / or authorized to the reporting WTRU. The suggested time pattern may be received from a neighboring WTRU and / or determined by the in-coverage WTRU based on information it has available (e.g., autonomously). For example, the report may include one or more indices describing one or more resources within the resource pool (e.g., in time and / or frequency) that the out-of-coverage WTRU and the in-coverage WTRU have negotiated and / or pre-configured for use with the out-of-coverage network link.

[0405] A WTRU-triggered report may include location information. The location information may be associated with the reporting WTRU and / or may be associated with the report. A WTRU (e.g., transmitting and / or receiving) may determine its location, for example, based on a cell ID, GPS information, and / or other location information, and attach the location information to the report.

[0406] The report triggered by the WTRU may include identity information. The identity information may include the identity of the detected out-of-coverage WTRU and / or the identity of the WTRU transmitting the message (e.g., on a synchronization channel). The identity may include a WTRU-specific ID, a ProSe ID, a ProSe group ID, a ProSe application ID, and / or the like. The triggered report may include information related to one or more services (e.g., one or more service identities) for the detected out-of-coverage WTRU and / or the WTRU transmitting the message. This information may be used, for example, to establish a relay service.

[0407] The report may include a specific number of resources, subframes, and / or time durations over which it may expect to receive data and / or receive data (e.g., as determined by a control message, scheduling assignment, broadcast message, etc.).

[0408] A WTRU-triggered report may include information regarding the presence and / or absence of an out-of-coverage WTRU. An indication of when an in-coverage WTRU detects an out-of-coverage WTRU requesting and / or providing PS service, an indication of when an in-coverage WTRU stops detecting an out-of-coverage WTRU (e.g., using measurements), and / or an indication of when an out-of-coverage WTRU stops requesting relay service and / or when the WTRU detects a D2DSS from a neighboring WTRU may be included in the report.

[0409] The WTRU may use the SFN (System Frame Number) and / or timer reference.

[0410] The WTRU-triggered report may include information related to the reason that triggered the transmission of the report, request, and / or transmission message (e.g., via a synchronization message). The reason for triggering the report may include a request to initiate ProSe discovery and / or communication with a device that may operate on another frequency, detection of a neighboring WTRU with which to communicate, a neighboring WTRU that is no longer available, a new WTRU that is detected, a change in mode and / or configuration request, a request to stop ProSe service, and / or the like.

[0411] The WTRU may use triggers. The WTRU may trigger reporting based on configuration, a request for a method, and / or transmission of a method (e.g., via a synchronization message). The WTRU may initiate a transmission when it receives L3 signaling requesting the WTRU to initiate a report and / or message transmission, and / or when the WTRU is configured for such reporting and another trigger initiates the transmission of the report. The signaling may be specific to D2D and / or prose services (e.g., communication and / or discovery) and / or may be WTRU-specific (e.g., applicable to any identity).

[0412] The trigger for reporting may be event-based. For example, the trigger may be based on detection of a neighboring WTRU, departure of a neighboring WTRU, a request to initiate ProSe service and / or initiate discovery, a change in resource allocation and / or pattern used by a neighboring WTRU, and / or the like.

[0413] A report may be triggered when an in-coverage WTRU detects an out-of-coverage WTRU. The WTRU may detect a neighboring WTRU based on received D2DSS, synchronization messages, and / or data received from neighboring WTRUs requesting a connection (e.g., solicited and / or unsolicited mode) and / or WTRUs performing PS communications with which the in-coverage WTRU can communicate (e.g., the WTRUs belong to the same group and / or are allowed to communicate according to the ProSe configuration). The report may be triggered when the in-coverage WTRU detects that the out-of-coverage WTRU is no longer available and / or the out-of-coverage WTRU is no longer requesting service.

[0414] The WTRU may trigger a request and / or report upon receiving an application request from a server to initiate a ProSe service. Requests and / or mode requests and / or reports from an in-coverage WTRU may enable the WTRU to detect and / or discover out-of-coverage WTRUs. The network may configure the WTRU for additional reporting, for example, once a neighboring WTRU has been detected and / or report to the network a request for an opportunity to communicate with the discovered WTRU. The WTRU may trigger a report upon determining that a neighboring WTRU has changed mode and / or resource configuration.

[0415] The trigger may be based on measurements and / or other detections of the WTRU. The WTRU may trigger a report, a request for a pattern, and / or the transmission of a pattern (e.g., via a synchronization message) when the WTRU is connected to a higher priority synchronization source and / or when the WTRU detects another WTRU transmitting synchronization that is derived from a lower priority source (e.g., a first WTRU is connected to an eNB and detects a second WTRU that is transmitting a synchronization signal and is connected to another WTRU and / or another synchronization source). The trigger may be when the WTRU detects a second WTRU that is not connected to the eNB. The trigger may be when the WTRU detects a second WTRU operating at a frequency other than its operating frequency. The trigger may be when the WTRU detects a second WTRU that belongs to the same group (e.g., the second WTRU is allowed to communicate with the first WTRU). The trigger may be when the WTRU receives data from the second WTRU and determines that the WTRU is not in coverage of the eNB (e.g., if there is no D2DSS, SCI, SSS, other control signals, and / or messages, this may use an indication in the SA that the WTRU is not in coverage). The trigger may be when the WTRU detects different transmission patterns from different synchronization sources.

[0416] The trigger for reporting may be periodic. The WTRU may initiate reporting periodically, for example, if there are one or more (e.g., a possibly configurable number) transmissions applicable to the reporting period. Reporting may cease when the WTRU detects that the out-of-coverage WTRU is no longer available (e.g., based on measurements) and / or the out-of-coverage WTRU stops requesting service.

[0417] The trigger for reporting may be aperiodic. The WTRU may initiate reporting based on the receipt of control signaling requesting the WTRU to perform reporting. The signaling may be received from a network node and / or may be dedicated signaling and / or signaling applicable to multiple WTRUs (e.g., received on a broadcast channel and / or a common control channel).

[0418] The WTRU may transmit the report using L2 (e.g., MAC) signaling (e.g., as a MAC control element), L3 (e.g., RRC) signaling (e.g., as an RRC PDU that is part of a reporting procedure), and / or higher layer signaling (e.g., such as NAS signaling and / or application signaling). For example, the WTRU may receive control signaling on a PDCCH (e.g., an aperiodic request) that may trigger such a report. The WTRU may assemble the report as a MAC control element and / or include it in an uplink transmission (e.g., its next uplink transmission). The eNB may be the end of the reporting procedure.

[0419] The WTRU may receive a request on a signaling radio bearer (SRB) as an RRC PDU that triggers such a report. The WTRU may assemble the report as an RRC PDU and / or make it available for transmission on the SRB of interest.

[0420] The WTRU may trigger reporting at the application level. For example, the WTRU may assemble an application layer control packet and / or make it available for transmission, such as an RRC PDU and make it available for transmission on the SRB of interest (e.g., in the case of NAS) and / or as user plane data and make it available for transmission on the corresponding DRB. The ProSe and / or application server may be the end point of the reporting process.

[0421] The WTRU may trigger a report. If the WTRU is in RRC IDLE mode, the WTRU may initiate a transition to CONNECTED mode and / or transmit a report according to the applicable signaling method. The WTRU may remain in IDLE mode and / or delay transmission of a report until it moves to CONNECTED mode, for example, if RRC and / or higher layer protocols are used.

[0422] Upon receiving the report, the WTRU may perform one or more of the following actions. The network and / or control node receiving the report may analyze the resource pool information and perform one or more of the following, for example, based on reports received from multiple sources. The network and / or control node may determine which resources within the resource pool it may allow the in-coverage WTRU to communicate. The network and / or control node may initiate steps to reconfigure resources for one or more WTRUs. The network and / or control node may use this information to avoid scheduling the WTRU for a given resource and / or time period. For example, the eNB may determine a gap pattern for the in-coverage WTRU and configure the gap pattern for the WTRU.

[0423] Upon receiving the report, the eNB may determine, provide, and / or configure a gap and / or time pattern for the WTRU. The gap pattern may be a bitmask and may indicate TTIs when the WTRU may not be scheduled for normal communications and / or the pattern may correspond to a period, cycle, and / or duration within a period (e.g., every period) during which the WTRU may not be scheduled for communications with the eNB. Upon receiving the report, the eNB may analyze the requested gap pattern and, if it does not consider it to be efficient, may provide a new gap pattern for the WTRU.

[0424] A WTRU may switch to an out-of-coverage link with a neighboring WTRU using an intermittent pattern. The WTRU may send an intermittent pattern to the out-of-coverage WTRU and / or send a new intermittent pattern received from the eNB to the out-of-coverage WTRU.

[0425] The eNB may remove the gap configuration, for example, when the report includes an indication notifying the eNB that the out-of-coverage WTRU is unavailable and / or no longer requesting service.

[0426] Although the features and elements are described above in particular combinations, it will be understood by those skilled in the art that each feature or element can be used alone or in various combinations with other features and elements. In addition, the methods described herein may be implemented in a computer program, software, or firmware incorporated into a computer-readable storage medium for execution by a computer or processor. Examples of computer-readable media include electronic signals (transmitted via a wired or wireless connection) and computer-readable storage media. Examples of computer-readable storage media include, but are not limited to, read-only memory (ROM), random access memory (RAM), registers, cache memory, semiconductor storage devices, magnetic media such as internal and removable disks, magneto-optical media, and optical media (such as CD-ROMs and digital versatile disks (DVDs)). A processor associated with software may be used to implement a radio frequency transceiver used in a WTRU, a WTRU, a terminal, a base station, an RNC, or any host.

Claims

1. A wireless transmit receive unit (WTRU), comprising: A processor configured to: Receiving a system information block SIB from a network device; as well as Based at least on information included in the SIB and a determination that the WTRU has device-to-device data to transmit: Sending a connection establishment request to the network device; as well as After the connection establishment request is sent to the network device and before an indication of resource rejection or resource allocation is received from the network device, the device-to-device data is transmitted, wherein the device-to-device data is transmitted using one or more resources autonomously selected by the WTRU from a resource pool.

2. The WTRU of claim 1 , wherein: If the resource allocation is received from the network device, the processor is further configured to switch from using the resource pool for device-to-device communication to using the resources indicated by the resource allocation for device-to-device communication.

3. The WTRU of claim 1 , wherein the device-to-device data is further transmitted based on a determination by the WTRU that it is within coverage of the network device.

4. The WTRU of claim 1 , wherein the device-to-device data is transmitted while a radio resource control timer associated with the connection establishment request is running.

5. The WTRU of claim 1 , wherein the resource pool is configured to be used by the WTRU for device-to-device communication during exceptional circumstances.

6. The WTRU of claim 1 , wherein the processor is configured to receive the SIB from the network device while the WTRU is in a Radio Resource Control (RRC) idle operation.

7. The WTRU of claim 1 , wherein the resource pool is indicated by the SIB.

8. A method implemented by a wireless transmit receive unit (WTRU), the method comprising: Receiving a system information block SIB from a network device; as well as Based at least on information included in the SIB and a determination that the WTRU has device-to-device data to transmit: Sending a connection establishment request to the network device; as well as After the connection establishment request is sent to the network device and before an indication of resource rejection or resource allocation is received from the network device, the device-to-device data is transmitted, wherein the device-to-device data is transmitted using one or more resources autonomously selected by the WTRU from a resource pool.

9. The method according to claim 8, wherein If the resource allocation is received from the network device, the method further includes switching from using the resource pool for device-to-device communication to using the resources indicated by the resource allocation for device-to-device communication.

10. The method of claim 8, wherein the device-to-device data is further transmitted based on a determination that the WTRU is within coverage of the network device.

11. The method according to claim 8, wherein The device-to-device data is transmitted while a radio resource control timer associated with the connection establishment request is running.

12. The method of claim 8, wherein the resource pool is configured to be used by the WTRU for device-to-device communication during exceptional circumstances. The method according to claim 8 , wherein the resource pool is indicated by the SIB.

Images