Device-to-device (D2D) pre-emption and access control

JP2025041934AActive Publication Date: 2025-03-26INTERDIGITAL PATENT HOLDINGS INC
View PDF 0 Cites 0 Cited by

Patent Information

Application Number
JP2024230780
Authority / Receiving Office
JP · JP
Patent Type
Applications
Current Assignee / Owner
Priority Date
2015-05-13
Filing Date
2024-12-26
Publication Date
2025-03-26
Estimated Expiration
2035-08-06

Smart Images

  • Figure 2025041934000001_ABST
    Figure 2025041934000001_ABST
Patent Text Reader

Abstract

To provide systems and methods for determining access control and channel and signaling priority that contemplate priority reception and / or priority transmission related to D2D relaying.SOLUTION: In a communication system, a wireless transmit / receive unit (WTRU) may comprise a processor configured, at least in part, to determine device-to-device (D2D) data to be transmitted. The WTRU may determine if the D2D data may be transmitted. The WTRU may determine available scheduling assignment (SA) resources used for priority based D2D data signals. The WTRU may select one or more available SA resources used for priority based D2D data signals. The WTRU may transmit the D2D data, where the D2D data may be transmitted on the selected SA resources.SELECTED DRAWING: Figure 5
Need to check novelty before this filing date? Find Prior Art

Description

[Technical field]

[0001] CROSS-REFERENCE TO RELATED APPLICATIONS This application claims the benefit of U.S. Provisional Patent Application No. 62 / 034,115, filed August 6, 2014, U.S. Provisional Patent Application No. 62 / 144,132, filed April 7, 2015, and U.S. Provisional Patent Application No. 62 / 161,108, filed May 13, 2015, the disclosures of all of which are incorporated by reference in their entireties for all purposes as if fully set forth herein. [Background technology]

[0002] Device-to-Device (D2D) communication may be utilized for various purposes, such as public safety communication. D2D communication may be associated with standardized technologies such as LTE, IEEE, etc. In LTE systems, access control and / or priority handling may be used to arbitrate access to and / or use of radio resources by terminals. Summary of the Invention

[0003] Systems, means, and methods for determining access control and channel and signaling priorities are disclosed. A wireless transmit / receive unit (WTRU) may comprise a processor configured to at least partially determine device-to-device (D2D) data to be transmitted. The WTRU may determine whether the D2D data may be transmitted. The WTRU may determine available scheduling assignment (SA) resources to be used for a priority-based D2D data signal. The WTRU may select one or more available SA resources to be used for the priority-based D2D data signal. The WTRU may transmit the D2D data, and the D2D data may be transmitted on the selected SA resources.

[0004] The WTRU may be configured to select available SA resources from a preconfigured set of SA resources. The WTRU may be configured to receive configuration signaling and / or determine available SA resources from the received configuration signaling.

[0005] Embodiments contemplate, for example, priority reception and / or priority transmission for D2D relay.Embodiments contemplate signaling regarding the use of segregated (e.g., guaranteed) resources.

[0006] A wireless transmit / receive unit (WTRU) may comprise a receiver. The receiver may be configured to receive an assignment of one or more radio resources for one or more scheduling assignments (SAs). The WTRU may comprise a processor. The processor may be configured to determine a first frequency domain SA (FD SA) pool. The first FD SA pool may include one or more SAs assigned to at least one of the first priority device-to-device (D2D) transmissions. The processor may be configured to determine a second FD SA pool. The second FD SA pool may include one or more SAs assigned to at least one of the second priority D2D transmissions. The WTRU may comprise a transmitter. The transmitter may be configured to transmit at least one first priority D2D transmission using at least one radio resource for one or more SAs from the first FD SA pool. The transmitter may be configured to transmit at least one second priority D2D transmission using at least one radio resource for one or more SAs from the second FD SA pool.

[0007] A wireless transmit / receive unit (WTRU) may be capable of device-to-device (D2D) communication. The WTRU may comprise a receiver. The receiver may be configured to receive at least one of a first D2D channel or a first D2D signal. The WTRU may comprise a processor. The processor may be configured to determine whether at least one of a second D2D channel or a second D2D signal is to be transmitted while at least one of the first D2D channel or the first D2D signal is being received. The processor may be configured to determine a relative priority between at least one of the first D2D channel or the first D2D signal and at least one of the second D2D channel or the second D2D signal upon determining that at least one of the second D2D channel or the first D2D signal is to be transmitted while at least one of the first D2D channel or the first D2D signal is being received. The processor may be configured to determine a number of D2D subframes to be used for receiving whether the first D2D channel or signal or the second D2D channel or signal has a higher relative priority.

[0008] A wireless transmit / receive unit (WTRU) may be capable of device-to-device (D2D) communication. The WTRU may comprise a processor. The processor may be configured to determine to transmit a preemption indication. The processor may be configured to determine to transmit the preemption indication via a scheduling assignment (SA). The WTRU may comprise a transmitter. The transmitter may be configured to transmit the SA as part of a control signal to another WTRU capable of D2D communication.

[0009] A wireless transmit / receive unit (WTRU) may comprise a receiver. The receiver may be configured to receive an assignment of one or more radio resources for one or more scheduling assignments (SAs). The WTRU may comprise a processor. The processor may be configured to determine a first SA pool. The first SA pool may include one or more SAs assigned to at least one of the first priority device-to-device (D2D) transmissions. The processor may be configured to determine a second SA pool. The second SA pool may include one or more SAs assigned to at least one of the second priority D2D transmissions. The processor may be configured to compare a number of first priority scheduling occurrences associated with one or more resources for one or more SAs of the first SA pool to a threshold. The WTRU may comprise a transmitter. The transmitter may be configured to transmit at least one first priority D2D transmission using at least one radio resource for one or more SAs from the first SA pool when the number is equal to or exceeds the threshold. [Brief description of the drawings]

[0010] A more detailed understanding may be had from the following description, given by way of example in conjunction with the accompanying drawings, in which: [Figure 1A] FIG. 1 is a system diagram illustrating an example communication system in which one or more disclosed embodiments may be implemented. [Figure 1B] 1B is a system diagram illustrating an example wireless transmit / receive unit (WTRU) that may be used within the communications system illustrated in FIG. 1A. [Figure 1C] A system diagram illustrating an example radio access network and an example core network that may be used within the communication system illustrated in FIG. 1A. [Figure 1D] A system diagram illustrating another example radio access network and an example core network that may be used within the communication system illustrated in FIG. 1A. [Figure 1E] A system diagram illustrating another example radio access network and an example core network that may be used within the communication system illustrated in FIG. 1A. [Diagram 2] A diagram showing an example of priority-based access via TDM in SA and D2D data subframes. [Diagram 3] FIG. 13 illustrates an example of priority-based access for D2D communication via TDM of SA in a shared D2D data subframe. [Figure 4] FIG. 13 illustrates an example of priority-based access for D2D communication via FDM in SA and D2D data subframes. [Diagram 5] FIG. 13 illustrates an example of priority-based access for D2D communication via FDM in SA in a shared D2D data subframe. [Figure 6] FIG. 13 illustrates an example of priority-based access via different resource allocation densities (e.g., TDM) for a D2D subframe pool. [Figure 7] 1 illustrates an example of priority-based access via different resource allocation densities (e.g., transmission patterns). [Figure 8] FIG. 13 illustrates an example of priority-based access for D2D data using persistence parameters (e.g., SA). [Figure 9] FIG. 13 illustrates an example of prioritized reception of a high priority channel by a D2D terminal having FDD half-duplex operation. [Figure 10] 1 is a diagram of an example of multiple simultaneously received D2D channels (eg, voice). [Figure 11] FIG. 1 is a diagram of an example of multiple D2D channels (eg, voice and data) to be transmitted simultaneously. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

[0011] Next, a detailed description of exemplary embodiments will be described with reference to various figures. It should be noted that, although this description provides detailed examples of possible implementations, the details are intended to be examples and in no way limit the scope of application. The article "a" as used herein can be understood to mean, for example, "one or more" or "at least one" unless further limited or characterized.

[0012] 1A is a 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, broadcasts, etc., to multiple wireless users. The communication system 100 may enable the multiple wireless users to access such content through sharing of system resources, including wireless bandwidth. For example, the communication system 100 may use 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.

[0013] 1A, the communications system 100 may include wireless transmit / receive units (WTRUs) 102a, 102b, 102c, and / or 102d (which may be referred to generally or collectively as WTRUs 102), a radio access network (RAN) 103 / 104 / 105, a core network 106 / 107 / 109, a public switched telephone network (PSTN) 108, the Internet 110, and other networks 112, although it will be recognized that the disclosed embodiments contemplate 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 transmit and / or receive wireless signals and may include user equipment (WTRUs), mobile stations, fixed or mobile subscriber units, pagers, cellular telephones, personal digital assistants (PDAs), smartphones, laptops, netbooks, personal computers, wireless sensors, consumer electronic devices, and the like.

[0014] The communications 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 communications networks, such as the core network 106 / 107 / 109, the Internet 110, and / or the network 112. By way of example, the base stations 114a, 114b may be a base station transceiver station (BTS) Node B, eNode B, Home Node B, Home eNode B, site controller, access point (AP), wireless router, and the like. Although the base stations 114a, 114b are each shown as a single element, it will be appreciated that the base stations 114a, 114b may include any number of interconnected base stations and / or network elements.

[0015] The base station 114a may be part of the RAN 103 / 104 / 105, which may also include other base stations and / or other network elements (not shown), such as a base station controller (BSC), a radio network controller (RNC), relay nodes, etc. The base station 114a and / or the base station 114b may be configured to transmit and / or receive wireless signals within a particular geographic area, which may be referred to as a cell (not shown). The cells may be further 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 for each sector of the cell. In another embodiment, the base station 114a may use multiple-input multiple-output (MIMO) technology and thus utilize multiple transceivers for each sector of the cell.

[0016] 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).

[0017] More specifically, as mentioned above, the communication system 100 may be a multiple access system and may use 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 establish the air interface 115 / 116 / 117 using Wideband CDMA (WCDMA). 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).

[0018] 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).

[0019] In other embodiments, the base station 114a and the WTRUs 102a, 102b, 102c may implement a radio technology such as IEEE 802.16 (e.g., 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 rate for GSM Evolution (EDGE), GSM EDGE (GERAN), and others.

[0020] The base station 114b in FIG. 1A may be, for example, a wireless router, a Home NodeB, a Home eNodeB, or an access point, and may utilize any suitable RAT to facilitate wireless connectivity in a localized area, such as a place of business, a home, a vehicle, a campus, and 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. As shown in FIG. 1A, the base station 114b may have a direct connection to the Internet 110. Thus, the base station 114b may not be required to access the Internet 110 via the core network 106 / 107 / 109.

[0021] The RAN 103 / 104 / 105 may be in communication with a core network 106 / 107 / 109, which may be any type of network configured to provide voice, data, application, and / or Voice over Internet Protocol (VoIP) services for 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, prepaid calling, Internet connectivity, video distribution, etc., and / or perform high-level security functions such as user authentication. Although not shown in FIG. 1A, 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 that use 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 utilize E-UTRA radio technology, the core network 106 / 107 / 109 may also be in communication with another RAN (not shown) that uses GSM radio technology.

[0022] The core networks 106 / 107 / 109 may also act as gateways 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 providing plain old telephone service (POTS). The Internet 110 may include a global system of interconnected computer networks and devices using common communication protocols such as Transmission Control Protocol (TCP), User Datagram Protocol (UDP), and Internet Protocol (IP) in the TCP / IP Internet protocol suite. The networks 112 may include wired or wireless communication networks owned and / or operated by other service providers. For example, the networks 112 may include another core network connected to one or more RANs that may use the same RAT as the RANs 103 / 104 / 105 or a different RAT.

[0023] Some or all of the WTRUs 102a, 102b, 102c, 102d in the communications system 100 may include multi-mode capabilities, e.g., the WTRUs 102a, 102b, 102c, 102d may include multiple transceivers for communicating with different wireless networks over different wireless links. For example, the WTRU 102c shown in FIG. 1A may be configured to communicate with a base station 114a that may use a cellular-based wireless technology and a base station 114b that may use an IEEE 802 wireless technology.

[0024] Figure 1B is a system diagram of an example WTRU 102. As shown in Figure 1B, 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 source 134, a Global Positioning System (GPS) chipset 136, and other peripherals 138. It will be appreciated that the WTRU 102 may include any sub-combination of the foregoing elements while remaining consistent with an embodiment. Also, embodiments contemplate that the base stations 114a and 114b and / or nodes that they may represent, such as, but not limited to, a base station transceiver station (BTS), a Node B, a site controller, an access point (AP), a home Node B, an evolved home Node B (eNodeB), a home evolved Node B (HeNB), a home evolved Node B gateway, and a proxy node, among others, may include some or all of the elements shown in FIG. 1B and described herein.

[0025] The processor 118 may be a general purpose processor, a special purpose processor, a conventional processor, a digital signal processor (DSP), multiple 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, and the like. The processor 118 may perform signal coding, data processing, power control, input / output processing, and / or any other function 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 FIG. 1B depicts the processor 118 and the transceiver as separate components, it will be appreciated that the processor 118 and the transceiver 120 may be incorporated together in an electronic package or chip.

[0026] The transmit / receive element 122 may be configured to transmit signals to or receive signals from a base station (e.g., base station 114a) over 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 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.

[0027] 1B as a single element, the WTRU 102 may include any number of transmit / receive elements 122. More specifically, the WTRU 102 may use 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 receiving wireless signals over the air interface 115 / 116 / 117.

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

[0029] The processor 118 of the WTRU 102 may be coupled to and may receive user input data from 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). 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 suitable type of memory, such as a non-removable memory 130 and / or a removable memory 132. The non-removable memory 130 may include a random access memory (RAM), a 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, and the like. In other embodiments, the processor 118 may access information from, or store data in, memory that is not physically located on the WTRU 102, such as on a server or home computer (not shown).

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

[0031] The processor 118 may also be coupled to a 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 instead of information from the GPS chipset 136, the WTRU 102 may receive location information over the air interface 115 / 116 / 117 from a base station (e.g., base stations 114a, 114b) and / or determine its location based on the timing of signals being received from two or more nearby base stations. It will be appreciated that the WTRU 102 may acquire location information by way of any suitable position determination method while remaining consistent with an embodiment.

[0032] The processor 118 may further be coupled to other peripherals 138, which may include one or more software and / or hardware modules that provide additional features, functionality, and / or wired or wireless connectivity. For example, the peripherals 138 may include an accelerometer, an electronic 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 handset, a Bluetooth module, a frequency modulated (FM) radio unit, a digital music player, a media player, a video game player module, an Internet browser, and the like.

[0033] 1C is a system diagram of the RAN 103 and the core network 106 according to an embodiment. As previously discussed, the RAN 103 may communicate with the WTRUs 102a, 102b, 102c over the air interface 115 using UTRA radio technology. The RAN 103 may also be in communication with the core network 106. As shown in FIG. 1C, 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) within 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.

[0034] As shown in FIG. 1C, Node Bs 140a, 140b may be in communication with RNC 142a. Additionally, Node B 140c may be in communication with RNC 142b. Node Bs 140a, 140b, 140c may communicate with their respective RNCs 142a, 142b via an Iub interface. RNCs 142a, 142b may be in communication with each other via an Iur interface. Each of RNCs 142a, 142b may be configured to control its respective Node B 140a, 140b, 140c to which it is connected. Additionally, each of RNCs 142a, 142b may be configured to perform or support other functions such as outer loop power control, load control, admission control, packet scheduling, handover control, macro diversity, security functions, data encryption, and the like.

[0035] 1C 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 foregoing elements is shown as part of the core network 106, it will be appreciated that any one of these elements may be owned and / or operated by an entity other than a core network operator.

[0036] The RNC 142a in the RAN 103 may be connected to an 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 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 land-line communications devices.

[0037] The RNC 142a in the RAN 103 may also be connected to an SGSN 148 in the core network 106 via an IuPS interface. The SGSN 148 may be connected to a GGSN 150. The SGSN 148 and 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.

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

[0039] 1D is a system diagram of the RAN 104 and the core network 107 according to an embodiment. As previously mentioned, the RAN 104 may communicate with the WTRUs 102a, 102b, 102c over the air interface 116 using E-UTRA radio technology. The RAN 104 may also be in communication with the core network 107.

[0040] The RAN 104 may include eNodeBs 160a, 160b, 160c, although it will be appreciated that the RAN 104 may include any number of eNodeBs while remaining consistent with an embodiment. The eNodeBs 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 eNodeBs 160a, 160b, 160c may implement MIMO techniques. Thus, for example, the eNodeB 160a may use multiple antennas to transmit wireless signals to and receive wireless signals from the WTRU 102a.

[0041] 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 of users on the uplink and / or downlink, and the like. As shown in FIG 1D, the eNodeBs 160a, 160b, 160c may communicate with each other over an X2 interface.

[0042] 1D may include a mobility management gateway (MME) 162, a serving gateway 164, and a packet data network (PDN) gateway 166. Although each of the foregoing elements is shown as part of the core network 107, it will be appreciated that any one of these elements may be owned and / or operated by an entity other than a core network operator.

[0043] The MME 162 may be connected to each of the eNodeBs 160a, 160b, 160c in the RAN 104 via an S1 interface and may act 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 initial attach of the WTRUs 102a, 102b, 102c, and the like. The MME 162 may also provide a control plane function for switching between the RAN 104 and other RANs (not shown) that use other radio technologies, such as GSM or WCDMA.

[0044] The serving gateway 164 may be connected to each of the eNodeBs 160a, 160b, 160c in the RAN 104 via an S1 interface. The serving gateway 164 may generally route and forward user data packets to / from the WTRUs 102a, 102b, 102c. The serving gateway 164 may also perform other functions, such as anchoring the user plane during eNodeB handover, 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.

[0045] The serving gateway 164 may also be connected to a 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.

[0046] 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 communicate with an IP gateway (e.g., an IP Multimedia Subsystem (IMS) server) that interfaces between the core network 107 and the PSTN 108. Additionally, the core network 107 may provide the WTRUs 102a, 102b, 102c with access to networks 112, which may include other wired or wireless networks owned and / or operated by other service providers.

[0047] 1E 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 communicates with the WTRUs 102a, 102b, 102c over the air interface 117 using IEEE 802.16 radio technology. As will be further described below, communication links between different functional entities of the WTRUs 102a, 102b, 102c, the RAN 105, and the core network 109 may be defined as reference points.

[0048] 1E, the RAN 105 may include base stations 180a, 180b, 180c and an ASN gateway 182, although it will be appreciated that the RAN 105 may include any number of base stations and ASN gateways 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 each 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 techniques. 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 handoff triggering, tunnel establishment, radio resource management, traffic classification, quality of service (QoS) policy enforcement, and the like. The ASN gateway 182 may act as a traffic aggregation point and may be responsible for paging, caching of subscriber profiles, routing to the core network 109, and the like.

[0049] 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 standard. Additionally, 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 that may be used for authentication, authorization, IP host configuration management, and / or mobility management.

[0050] 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 the transfer of data between 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.

[0051] 1E, 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 as an R3 reference point that includes protocols for facilitating, for example, data transfer and mobility management capabilities. The core network 109 may include a Mobile IP Telephony Agent (MIP-HA) 184, an Authentication, Authorization, and Accounting (AAA) server 186, and a gateway 188. Although each of the foregoing elements is shown as part of the core network 109, it will be appreciated that any one of these elements may be owned and / or operated by an entity other than a core network operator.

[0052] The MIP-HA may be responsible for IP address management and may enable the WTRUs 102a, 102b, 102c to roam 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. Additionally, the gateway 188 may provide the WTRUs 102a, 102b, 102c with access to the networks 112, which may include wired or wireless networks owned and / or operated by other service providers.

[0053] Although not shown in FIG 1E, 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 those other ASNs may be defined as an R4 reference point, which may include protocols for coordinating mobility of the WTRUs 102a, 102b, 102c between the RAN 105 and those other ASNs. The communication link between the core network 109 and those 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.

[0054] With respect to 3GPP and / or LTE based radio access, support for D2D communications may enable cost-effective, high-capacity public safety communications using LTE technology. This may be motivated by the desire to harmonize radio access technologies across jurisdictions to lower the CAPEX and OPEX of radio access technologies available for use in public safety (PS) type applications. This may be motivated by LTE, as a scalable wideband radio solution may enable efficient multiplexing of different service types such as voice and video.

[0055] Because PS applications may utilize (and typically require) wireless communications in areas that may not be under radio coverage of LTE networks, e.g., in tunnels, deep basements, and / or after catastrophic system outages, there may be utility in supporting D2D communications for PS in situations where there is no operational network and / or prior to the arrival of a temporary deployed radio infrastructure. Even when operating in situations where an operational network infrastructure exists, PS communications may utilize (and typically require) higher reliability than civilian services.

[0056] For example, PS type applications among first responders may include direct push-to-talk voice services using multiple talkgroups. PS type applications may include services such as video push or video download that efficiently use the capabilities that LTE broadcast radio provides.

[0057] D2D communication may, for example, be available for PS type applications and / or civil use cases, if possibly deployed. For example, civil use may be utilities that often also require support for two-way radio communication in areas not covered by network infrastructure. D2D services such as discovery are suitable signaling mechanisms to enable proximity-based services and / or traffic offload using LTE-based radio access in civil use cases.

[0058] Access control may be disclosed herein.Priority handling may be disclosed herein.

[0059] In an LTE system, there may be access control and / or priority handling mechanisms that arbitrate access to and / or use of radio resources by terminals.

[0060] For example, a System Information Broadcast (SIB) message carried on the Broadcast Channel (BCH) may carry information on which access service class a terminal attempting to connect to a cell is allowed for, e.g., emergency only, maintenance only, and / or any type. Access control may be possible, for example, when a terminal device is connected to an LTE cell. For example, if more terminals are connected to a cell than can be reliably supported, the Access Stratum (AS) connection and / or the Non-Access Stratum (NAS) connection may be terminated from the network side. The terminal device may be redirected to a channel and / or bank of another radio access technology, such as GSM or 3G HSPA, in the operator's network.

[0061] Access control in existing LTE networks may exist in one or more (e.g., many) forms. Access control in LTE networks may have in common that a terminal device may be denied and / or restricted in access to radio resources by the network, for example, prior to a connection attempt and / or while connected to a cell.

[0062] LTE systems may provide techniques for priority handling of simultaneously running wireless services. Priority handling may be used to ensure higher quality of service (QoS) data streams, such as conversational voice, video, that can be served first and / or with guaranteed bit rate or guaranteed latency. Priority handling may be used to serve (e.g., serve first) control signaling (e.g., useful / essential control signaling).

[0063] For example, in an LTE system, priority handling of data with multiple users in the system may be possible by the base station scheduling (e.g., earlier) high priority data with real-time QoS constraints in the downlink (DL). Priority handling of data with multiple users in the system may be possible by the base station artificially reducing and / or throttling the service data rate for lower priority download type data. When supporting emergency calls, etc., the system may perform priority handling for E911 calls to ensure a (e.g., much) higher successful call setup percentage and / or a (e.g., much) lower occurrence of dropped calls than is normally guaranteed for normal voice calls. When a single terminal device has multiple types of data to transmit simultaneously, rules may specify that higher priority data is transmitted (e.g., earlier) if a UL transmission opportunity may be allowed. Lower priority data may be completed (e.g., later) when packets assigned to higher logical channel priorities complete their transmission, for example.

[0064] Priority handling from a single user perspective and / or from a system perspective may be performed in different ways in existing LTE systems, which may have in common that higher priority data may be transmitted (e.g., earlier) if possibly useful, and / or lower priority data may be preempted from transmission if simultaneous services have to be supported simultaneously.

[0065] D2D communication may use LTE-based radio access.

[0066] D2D communications using LTE-based radio access may be designed to operate in a network-controlled mode and / or in a WTRU-autonomous mode. The network-controlled mode may be referred to as Mode 1, and the WTRU-autonomous mode may be referred to as Mode 2. Mode 1 (network-controlled) may be possible under some conditions, e.g., if (e.g., only if) the D2D terminal is within radio range of an LTE base station. The D2D terminal may fall back to Mode 2 (WTRU-autonomous) operation, e.g., if it is unable to communicate with an LTE base station. In this case, it may generally use channel access parameters pre-stored in the terminal itself.

[0067] For D2D communication using Mode 1, an LTE base station may reserve a selected set of UL subframes to enable D2D transmission. The LTE base station may announce a set of UL subframes with associated parameters in which D2D communication for neighboring cells and / or Mode 2 terminals may be received. Less than all of the LTE system bandwidth (BW) may be available for D2D transmission in subframes reserved for D2D. For example, possibly when operating in Mode 1, radio resources for D2D communication may be granted to the D2D terminal by the serving cell. A D2D grant from the network may be preceded, for example, by a UL transmission by the terminal on the cellular UL indicating to the base station the amount of available D2D data. A D2D grant received by the D2D terminal from the LTE base station on the cellular DL may enable the D2D terminal to use some selected radio resources, e.g., some radio blocks (RBs) occurring in some subframes over a certain scheduling period.

[0068] A D2D terminal may transmit a Scheduling Assignment (SA) message in one or more sets of D2D subframes (e.g., a first set) and / or transmit D2D data in a set of D2D subframes (e.g., a second set) during a scheduling period. A Scheduling Assignment (e.g., and others) may include an identifier field, an MCS field, a resource indicator, and a TA field. A D2D data packet (e.g., and others) may include a MAC header with a source address and / or a destination address. Multiple logical channels may be multiplexed and / or transmitted by the WTRU as part of a single transport block (TB) in a D2D subframe.

[0069] For D2D communication using Mode 2, the D2D terminal may select (e.g., autonomously select) time / frequency radio resources. Channel access parameters, such as subframes to use for transmission of SA control messages and / or corresponding D2D data, scheduling periods, or monitoring subframes, may be pre-configured (e.g., typically pre-configured) and / or stored on the D2D terminal. Mode 2 terminals may follow the same or similar transmission behavior as Mode 1 terminals, e.g., they may transmit SA in a scheduling period followed by D2D data. The preceding UL traffic volume indication and / or DL ​​D2D grant phase may follow the same or similar transmission behavior as Mode 1 terminals.

[0070] For D2D communication in Mode 1 and Mode 2, D2D terminals may transmit auxiliary D2D signals, such as D2D synchronization signals and / or channel messages, that help the receiver to demodulate their transmissions.

[0071] D2D communications using LTE-based radio access may carry voice channels and / or data packets and / or data streams. D2D communications may include D2D discovery services. D2D discovery (e.g., unlike voice channels) may use (e.g., only use) small packet transmissions that may fit into one, two, or a few (e.g., at most) subframes. For example, these packets may contain application data announcing the availability of devices and / or SW applications to participate in D2D data exchange with terminals in the vicinity.

[0072] D2D discovery may or may not use the same or similar channel access protocol, such as may be used for D2D communication for voice and / or general D2D data. For D2D discovery services, such as when in the coverage of an LTE base station, D2D discovery resources may be allocated (e.g., allocated separately) from those used for D2D communication with voice or general D2D data. Radio resources for D2D discovery messages may be reserved by the eNB and / or may be recurring (e.g., periodically recurring) time-frequency radio resources in UL subframes (e.g., Type 1 discovery) and / or may be selected (e.g., autonomously) by the D2D terminal from a set of resources that may be assigned (e.g., explicitly assigned) to the D2D terminal (e.g., Type 2 discovery) by the LTE serving cell. The latter may be similar to D2D communication mode 1. Transmission of scheduling assignments may not be used when transmitting D2D discovery messages. A D2D terminal that transmits (eg, transmits only) a D2D discovery message may be used to transmit an auxiliary D2D synchronization signal that aids the receiver.

[0073] Access control mechanisms, priority handling mechanisms, and / or preemption mechanisms for D2D communications using LTE-based radio access equivalent to conventional LTE networks may be described herein.

[0074] D2D terminals, such as those for use in public safety applications, may be designed (e.g., inherently) to operate in the absence of a working LTE wireless network infrastructure. This may mean that these devices may be able to operate autonomously with respect to channel access and any handling of D2D data transmission. Unlike current LTE terminal devices that can be network controlled largely via control signaling message exchanges with the LTE network, D2D terminal devices may store (e.g., typically store) some (e.g., most, if not all) parameters that can determine their channel access and / or transmission behavior on the (U)SIM card and / or as part of the application software (SW).

[0075] Transmission procedures and / or channel access protocols for D2D communications using LTE-based radio access may not be designed to allow random access with differentiated priorities for individual devices and / or to allow data transmission with Quality of Service (QoS) considerations for D2D data. There may be mechanisms to deny, limit and / or restrict access to D2D radio resources for certain devices or users.

[0076] For example, among other scenarios, when in radio coverage of an LTE cell, some limitations may be imposed by the LTE serving cell on the allowable UL subframes that may be reserved for use by D2D terminals in the vicinity. Priority handling and channel access for different types of data transmitted by different users or from a given D2D user may not be deterministically ensured. Successful channel access for high priority terminals and successful transmission of higher priority data may be ensured, for example, in a statistical sense, if (e.g., only if) D2D radio resources in the LTE serving cell are over-provisioned. In situations without a working LTE radio network infrastructure, there may be less control over the use of D2D radio resources.

[0077] D2D terminals may not distinguish between different types of D2D data, for example with regard to radio resource allocation trade-offs.

[0078] D2D communications using LTE-based radio access may allow (e.g., implicit) differentiation of different types of received D2D communications, for example, when associating an encryption key or message integrity protection key used for a D2D SW application to secure a D2D data payload by a transmitting device, and a D2D service identifier. If the keys and identifiers are known, a transmitting or receiving D2D terminal may not be able to differentiate higher priority users and / or higher priority types of D2D data, for example, until it is able to (e.g., physically) demodulate and / or decode any such D2D transmission. D2D devices may not take into account the priorities of ongoing and / or planned D2D communications, for example, when determining their own transmission and / or reception behavior. A D2D terminal that is ready to transmit may not refrain from channel access until it has (e.g., physically) demodulated one or more channels, or all channels, such as in situations where there is ongoing critical D2D communication. A D2D terminal may not be configured (e.g., never be configured) with knowledge of one or more or all D2D identifiers and / or associated derived payload encryption and / or message integrity protection keys that may be used in the vicinity by other D2D terminals. This means that one or more (e.g., most) D2D terminals may be indifferent to the kind and / or type of D2D data that they attempt to decode and distinguish based on the received D2D payload content. Payloads may not be decoded by such D2D devices in the absence of trusted keys and / or associated identifiers. Information about the carried D2D payload may not be derived.

[0079] Mechanisms for D2D communications using LTE radio access technology may be described herein that may enable priority-based channel access, priority-based processing of D2D communications as a function of the type of D2D terminal and / or D2D data to ensure service availability and QoS, and / or preemption in critical situations. The availability of priority-based access and / or transmission mechanisms may enhance the efficiency of radio transmissions, improve the use of D2D radio resources, and / or improve channel availability and / or service availability for D2D users similar to conventional LTE networks.

[0080] The term D2D data may refer to D2D related communications between D2D terminals. For example, without loss of generality, D2D data may include data packets such as carrying voice or segments thereof, it may include IP packets or segments thereof such as used for file download or upload, streaming video or two-way video, it may include D2D control signaling, or it may include D2D discovery or D2D service or D2D availability messages, etc. Features disclosed herein may be described in the general context of 3GPP D2D communications, and the features may be applicable to other features such as, for example, D2D discovery.

[0081] D2D priority can be based on channel access. One or more (e.g., different) SAs and / or data pools can be used for priority-based access. The access mechanism can be based on radio resource sets (e.g., segregated radio resource sets).

[0082] Priority-based access for D2D communication may use radio resource sets that are segregated in the time domain and / or in the frequency domain.

[0083] A segregated radio resource set in the time and / or frequency domain for use for prioritized D2D access may be realized on radio resources that may be used for D2D service signaling such as Scheduling Assignment (SA), D2D data, D2D control, or D2D discovery, one of these D2D data signals / channels, and / or multiple of these D2D data signals / channels.

[0084] 2 is an example diagram of priority-based access via TDM in SA and D2D data subframes. Priority-based access for D2D communication may be achieved via time division multiplexing (TDM) of the SA and / or D2D data pools.

[0085] In the example of Fig. 2, there are N=2 different SA pools and their corresponding D2D data pools of M=2. Two different SA pools are defined over different and / or separate subframe subsets in the time domain. In Fig. 2, there are L1=1 subframes for SA per SA pool per scheduling period of P=160 ms. Two D2D data pools may be defined over different and / or separate subframe subsets. In Fig. 2, there are L2=18 available subframes per D2D data pool per scheduling period.

[0086] An SA pool (e.g., such as the first SA pool in FIG. 2) may carry SAs for associated D2D data transmissions (e.g., high priority D2D data transmissions) in a D2D data pool (e.g., the first D2D data pool) for the duration of a scheduling period. The high priority transmissions may correspond to responder talk groups (e.g., first responder talk groups) and / or high priority voice channels. An SA pool (e.g., such as the second SA pool in FIG. 2) may carry SAs for corresponding lower priority D2D transmissions in a D2D data pool (e.g., the second D2D data pool). The lower priority transmissions may be background file downloads and / or non-time critical exchanges of D2D service data.

[0087] A high priority D2D data transmission may be made on (e.g., only on) radio resources used by an SA (e.g., the first SA in FIG. 2) and / or a corresponding D2D data pool (e.g., the first D2D data pool in FIG. 2). A low priority D2D data transmission may be made on (e.g., only on) radio resources used for an SA (e.g., the second SA) and / or a D2D data pool (e.g., the second D2D data pool). An SA carried in a subframe of a high priority (e.g., the first) SA pool may not announce D2D data on radio resources for a low priority (e.g., the second) D2D data pool. An SA carried in a subframe of a low priority (e.g., the second) SA pool may not announce D2D data on radio resources for a high priority (e.g., the first) D2D data pool.

[0088] TDM in lower priority D2D transmissions may not be performed on higher priority SA / data pools, which may improve priority handling for D2D transmissions. Due to network controlled radio resource allocation of SA and / or D2D data on the high priority pool, low priority D2D devices and low priority D2D channels may not compete for segregated TDM radio resources. Due to WTRU autonomous contention resolution on such SA / data resources, low priority D2D devices and low priority D2D channels may not compete for segregated TDM radio resources. Due to random radio resource selection of SA / data by D2D terminals, low priority D2D devices and low priority channels may not compete for segregated TDM radio resources. Higher priority D2D data may have a (significantly) higher probability of being successfully transmitted during initial determination of radio resources and / or during ongoing transmissions due to reduced interference from lower priority D2D data. Legacy D2D terminals that are not capable of priority handling may be prevented from accessing the new higher priority SA / data pool via resource segregation.

[0089] 3 is an example diagram of priority-based access for D2D communication via TDM of SAs in a shared D2D data subframe. Priority-based access for D2D communication may be achieved via time division multiplexing (TDM) of the SA pool, such as while using a shared D2D data pool.

[0090] In Fig. 3, there are N=2 different SA pools and M=1 corresponding D2D data pool. The two different SA pools are defined over different and / or separate subframe subsets in the time domain. In Fig. 3, there are L1=1 subframes for SA per SA pool per scheduling period of P=160 ms. The D2D data pool has L2=38 available subframes per scheduling period.

[0091] An SA pool (e.g., the first SA pool in FIG. 3) may carry SAs for associated high priority D2D data transmissions. An SA pool (e.g., the second SA pool in FIG. 3) may carry SAs for associated lower priority D2D data transmissions.

[0092] A high priority D2D data transmission may be transmitted by (e.g., only by) using radio resources from a high priority SA pool (first SA pool). A lower priority D2D data transmission may be transmitted by (e.g., only by) using radio resources from a lower priority SA pool (second). SAs from the high priority SA pool (e.g., first SA pool) and / or the lower priority SA pool (e.g., second) may correspond to D2D data transmitted on shared radio resources of the D2D data pool.

[0093] Priority handling for D2D transmissions may be improved. For example, priority handling for D2D transmissions may be improved if lower priority D2D transmissions cannot be made on a higher priority SA pool. Due to network controlled radio resource allocation of SAs on a high priority pool, low priority D2D devices and low priority D2D channels may not compete for such isolated TDM radio resources. Due to WTRU autonomous contention resolution on such SA resources, low priority D2D devices and low priority D2D channels may not compete for such isolated TDM radio resources. Due to random radio resource selection determining SAs by D2D terminals, low priority D2D devices and low priority channels may not compete for such isolated TDM radio resources. Higher priority D2D data may have a (e.g., significantly) higher probability of being transmitted, e.g., due to interference and / or contention avoidance on SA radio resources. The priority-based access mechanism may be performed while preserving the principle of a shared D2D data pool and / or resource utilization (e.g., inherent resource utilization) efficiency.

[0094] 4 is an example diagram of priority-based access for D2D communication via FDM in SA and D2D data subframes. Priority-based access for D2D communication may be achieved via frequency division multiplexing (FDM) of the SA and D2D data pools.

[0095] In the example of FIG. 4, there are N=1 SA pools in the time domain and M=1 corresponding D2D data pools in the time domain. In FIG. 4, there are L1=2 subframes for SA per SA pool per scheduling period of P=160 ms. In FIG. 4, there are L2=38 available subframes in the D2D data pool per scheduling period. The radio resources in the SA pool include L2=2 distinct and separate radio block subsets in the frequency domain. The subframes including SAs may include SAs for high priority D2D data transmissions in RB10-30 and SAs for low priority D2D data in RB40-60. The subframes including D2D data may include high priority and / or low priority transmissions in (e.g., only in) RB10-30 and RB40-60 (e.g., respectively). These may be referred to as SA data pools and D2D data pools in the frequency domain.

[0096] A frequency domain SA pool (e.g., the first frequency domain SA pool in FIG. 4) may carry SA for an associated high priority D2D data transmission in a frequency domain D2D data pool (e.g., the first frequency domain D2D data pool in FIG. 4), for example, for the duration of a scheduling period. A frequency domain SA pool (e.g., the second frequency domain SA pool in FIG. 4) may carry SA for an associated lower priority D2D transmission in a frequency domain D2D data pool (the second frequency domain D2D data pool in FIG. 4).

[0097] A high priority D2D data transmission may be performed on (e.g., only on) radio resources in a frequency domain, such as a frequency domain used by an SA (e.g., a first SA) and / or a corresponding D2D data pool (e.g., a first D2D data pool). A lower priority D2D data transmission may be performed on (e.g., only on) radio resources used for an SA (e.g., a second SA) and / or a data pool (e.g., a second data pool) in a frequency domain. For example, an SA carried in a subframe of a high priority SA frequency domain (e.g., a first SA frequency domain) may not announce D2D data on radio resources used in a low priority D2D data (e.g., a second D2D data) frequency domain. An SA carried in a low priority frequency domain SA domain may not announce D2D data on radio resources in a high priority D2D data frequency domain (e.g., a first D2D data frequency domain) domain.

[0098] Priority handling for D2D transmissions may be improved, for example, if lower priority D2D transmissions may not occur on higher priority SA / data frequency domain pools. Low priority D2D devices and / or low priority channels may not compete for segregated FDM radio resources. Higher priority D2D data may have a higher (e.g., significantly higher) probability of being successfully transmitted during radio resource determination and / or ongoing transmission due to reduced interference from lower priority D2D data.

[0099] 5 is an example diagram of priority-based access for D2D communication via FDM of SA in a shared D2D data subframe. Priority-based access for D2D communication can be achieved via frequency division multiplexing (FDM) of the SA pool while using a shared D2D data pool.

[0100] In FIG. 5, there is an SA pool of N=1 in the time domain and a corresponding D2D data pool of M=1 in the time domain. In FIG. 5, there are L1=2 subframes for SA per scheduling period of P=160 ms. In FIG. 5, there are L2=38 available subframes in the D2D data pool per scheduling period. Radio resources in the SA pool may include different and / or separate radio block subsets of L2=2 in the frequency domain. Subframes containing SAs may include SAs for high priority D2D data transmissions in RBs 10-30 and SAs for low priority D2D data in RBs 40-60. These may be referred to as SA pools in the frequency domain. Subframes containing D2D data may include high priority transmissions and / or low priority transmissions, such as where specified in one or more (e.g., all) RBs.

[0101] A frequency domain SA pool (e.g., the first frequency domain SA pool in FIG. 5) may carry SAs for associated high priority D2D data transmissions, such as in a D2D data pool for the duration of a scheduling period. A frequency domain SA pool (e.g., the second frequency domain SA pool in FIG. 5) may carry SAs for associated lower priority D2D transmissions, such as in a D2D data pool.

[0102] A high priority D2D data transmission may be transmitted by (e.g., only) using radio resources from a high priority SA pool (e.g., a first SA pool) in the frequency domain. A lower priority D2D data transmission may be transmitted by (e.g., only) using radio resources used for a lower priority SA pool (e.g., a second SA pool) in the frequency domain. SAs from the high priority SA pool (e.g., a first SA pool) and / or the lower priority SA pool (e.g., a second SA pool) in the frequency domain may correspond to D2D data transmitted on shared radio resources of the D2D data pool.

[0103] Priority handling for D2D transmissions may be improved. For example, priority handling for D2D transmissions may be improved if lower priority D2D transmissions may not be performed on higher priority SA radio resources in the frequency domain. Due to network controlled radio resource allocation for SA on the high priority pool, low priority D2D devices and / or low priority channels may not compete for such isolated FDM radio resources. Due to contention resolution on such SA resources, low priority D2D devices and / or low priority channels may not compete for such isolated FDM radio resources. Due to random radio resource selection determining SA by D2D terminals, low priority D2D devices and low priority channels may not compete for such isolated FDM radio resources. Higher priority D2D data may have a higher (e.g., significantly higher) probability of being transmitted due to interference and / or contention avoidance on SA radio resources. The priority-based access mechanism may be performed while keeping the principle of a shared D2D data pool and / or resource utilization (e.g., inherent resource utilization) efficiency.

[0104] Priority-based access for D2D communication may be achieved via TDM and / or FDM of the SA and / or D2D data pools. The resource pools for SA and D2D data (e.g., both) may be isolated in frequency and / or time.

[0105] Priority-based access for D2D communication may be achieved, for example, via TDM and / or FDM of the SA pool while using a shared D2D data pool.

[0106] The examples described herein may be extended to the case of more than two priority classes with SA or data pools in the time and / or frequency domain. For example, N=M=4 priority categories corresponding to four different and / or separate subframe subsets for SA and data may be used. Radio recourse segregation using TDM or FDM may be extended to the case of more than L1=1 subframes allowed for SA per pool per scheduling period. Different lengths of the scheduling period may be used. SA transmission may correspond to D2D data transmitted in a later scheduling period and / or in multiple scheduling periods. For example, the principles of semi-persistent, time-limited and / or dynamically allowed D2D data transmission may be used together with TDM and / or FDM principles, independent of or in conjunction with the scheduling period. Time and / or frequency resources may be non-contiguous. The examples of SA and D2D data may be used for illustrative purposes. The principles of TDM and / or FDM radio resource segregation may be similarly described when using different D2D channels or signaling messages. For example, the D2D discovery message may be separated in TDM from the D2D control signaling.

[0107] The transmission opportunity may be determined, for example, by:

[0108] D2D transmission opportunities for D2D priority-based access using fully or partially isolated TDM / FDM radio resources may be advertised by a controlling device, which may be a D2D terminal and / or an LTE wireless network device such as a base station.

[0109] The controlling device may signal a set of radio resources (e.g., a first set of radio resources) to be used for high priority D2D data transmissions. The controlling device may signal a set of radio resources (e.g., a second set of radio resources) to be used for lower priority D2D data transmissions. The radio resource set may distinguish different types of D2D data and / or control or service messages. The radio resource set may include different parameter sets for different types of signaling. The controlling device may signal different sets of resources and / or for one or more sets or each set of resources, it may signal an associated priority level (e.g., or access class) that may be allowed to use the corresponding resource.

[0110] The controlling devices may signal (e.g., explicitly) their radio resource sets by using a shared control channel such as the BCH broadcast channel or the PD2DSCH broadcast channel. For example, system information on the BCH may include any one or both of the subframe number or subframe set, or a combination of frequency resources combined or associated with an access priority level. Such D2D access levels and / or priority levels may be given (e.g., explicitly). Such D2D access levels and / or priority levels may be derived (e.g., implicitly), for example, on the order in which they may be communicated. Such D2D access levels and / or priority levels may be given as part of an index list.

[0111] D2D transmission opportunities for D2D priority based access using fully or partially isolated TDM / FDM radio resources may be derived by the D2D terminal, for example, from observing and / or decoding known transmission formats and / or reference signals.

[0112] A controlling device may support D2D priority-based access and set up a corresponding radio resource set for use in its vicinity. For example, the controlling device may transmit a D2D signal (e.g., a first D2D signal) using a transmission format (e.g., a first transmission format) in a time / frequency resource (e.g., a first time / frequency resource) for high priority access. The controlling device may transmit a D2D signal (e.g., a second D2D signal) using a transmission format (e.g., a second transmission format) in a time / frequency resource (e.g., a second time / frequency resource) for lower priority access. A D2D signal (e.g., a first D2D signal) may be an SA using a payload field and / or code point indicating a high priority. A D2D signal (e.g., a second D2D signal) may be distinguished from another D2D signal (e.g., a first D2D signal) via its L1 transmission format, such as the selection of pilot symbols and / or coding sequences. A D2D terminal intending to transmit and / or receive D2D data can (e.g., implicitly) determine access and / or priority levels for time and / or frequency resources by observing such transmissions from another D2D terminal indicating and / or characterizing high and low priority radio resources from a controlling device. The controlling device can determine the relationship between observed D2D signals and / or used time / frequency resources. The D2D terminal can establish a list and / or database that can represent transmission opportunities for high or low priority D2D data obtained from occurrences of observed signals.

[0113] D2D transmission opportunities in the time or frequency domain for D2D priority based access using fully or partially isolated TDM / FDM radio resources may be derived by the D2D terminal from timing relationships, e.g. with respect to known and / or observable reference signals.

[0114] For example, such reference signals may be occurrences of timing and / or frequency acquisition signals such as D2DSS, DL Sync, or PD2DSCH. A receiving D2D terminal may determine the occurrence of such reference signals. A receiving D2D terminal may calculate expected occurrences in the time domain of transmission opportunities for high priority D2D data or low priority D2D data. The timing relationship may be performed and / or given via a formula, for example using an index or counter representing time as one parameter such as SFN. The timing relationship may be given by a bitmap and / or tabulated set of values. For example, a high priority D2D transmission opportunity may be given every 8th and 9th subframe starting from the measured occurrence of D2DSS from the transmitter, while a low priority D2D transmission opportunity may be given every 12th subframe, offset by 3 subframes from the first D2DSS occurrence.

[0115] The examples described herein may be extended to the use of more than two priority classes, or to the use of different timing relationships or different signaling format representations.

[0116] The access mechanism may be based on the use of radio resource transmission parameters.

[0117] Priority based access for D2D communication can be achieved, for example, through the use of different Radio Resource Transmission Parameters (RRPTs) for D2D data in the time and / or frequency domain, where the RRPTs for use with high or low priority D2D data may be characterized by different allocation densities in the time / frequency domain over a given time period.

[0118] Prioritized D2D access using different radio resource transmission patterns may be achieved on radio resources used for control signaling such as Scheduling Assignment (SA), data, D2D discovery, etc. for any one of the D2D data signals / channels, or for one or more (e.g., several) of these D2D data signals / channels.

[0119] 6 is an example diagram of priority-based access via different resource allocation densities for a D2D subframe pool, such as TDM, in which different numbers of subframes per scheduling period may be allocated and / or configured with time domain isolated resources for SA and D2D data for high and low priority D2D data (e.g., respectively).

[0120] In FIG. 6, a radio resource transmission (e.g., first radio resource transmission) pattern (RRTP) may be configured for high priority D2D data, allowing 31 D2D data subframes per 160 ms scheduling period, while a (e.g., second) RRTP for low priority D2D data allowing 15 subframes per scheduling period may be used.

[0121] A high priority SA pool (e.g., the first SA pool in FIG. 6) and / or a corresponding D2D data pool may be assigned a different amount of radio resources (e.g., twice as much) per time period, e.g., per scheduling period, than a low priority SA pool (e.g., the second SA in FIG. 6) and / or a corresponding D2D data pool.

[0122] Priority handling for D2D transmissions may be improved in that, for example, for the same resource usage efficiency per D2D transmission, lower priority D2D transmissions may take longer to complete compared to high priority D2D data transmissions. High priority D2D data transmissions may utilize more resource allocation space (e.g., a "bigger pipe") in time and / or frequency, which may improve their time to complete transmissions and / or improve their observable signal-to-noise and / or interference ratio (SINR) when compared to the (e.g., second) low priority SA and the low priority D2D data pool.

[0123] As shown in Figure 6, the time multiplexed SA and D2D data resources can be extended to TDM and can be applied to the SA radio resources while (e.g., only while) using a shared D2D data pool. The example shown in Figure 6 can be extended to frequency domain allocations for the SA or the D2D data pool, or for both.

[0124] The example shown in FIG. 6 may be adjusted, for example, by allowing the radio resource density over time to be adjusted for different transmission characteristics that may be expected for a high priority SA (e.g., the first high priority SA in FIG. 6) and D2D data pool when compared to that used for a low priority D2D (e.g., the second low priority D2D in FIG. 6) transmission opportunity. For example, if high priority D2D data consists primarily of a voice broadcast channel occupying 3 PRBs per subframe, where a total of 5 transmissions per 20 ms period may be used to maintain an operating SINR of 0-1 dB for a BLER at a target level of 2-4%, while low priority D2D data consists of D2D discovery using 2 PRBs and no repetitions to achieve detection reliability for an operating SINR of 5 dB, then the SA and data pool (e.g., the first SA and data pool) may be over-sized in an ordered approach (e.g., the first ordered approach), such as by taking into account (e.g., only taking into account) the expected number of retransmissions for the same or similar amount of offered traffic, adjusted by an over-provisioning factor for the higher priority traffic, as desired.

[0125] 7 is an example diagram of priority-based access via different resource allocation densities (e.g., transmission parameters), in which different numbers of subframes per scheduling period may be used by D2D terminals with time domain isolated resources for SA and D2D data, such as while transmitting high priority D2D data and low priority D2D data (e.g., respectively).

[0126] A radio resource transmission pattern (RRTP) (e.g., the first RRTP in FIG. 7) may be used by the D2D terminal for high priority D2D data, while the D2D terminal may use a different RRTP (e.g., the second RRTP in FIG. 7) for low priority D2D data.

[0127] In Fig. 7, a shared D2D data pool may be configured. A D2D transmitter intending to transmit high priority D2D data such as voice may transmit an SA indicating an RRTP (e.g., a first RRTP) that may result in the usage of 28 subframes over a 160 ms scheduling period. For transmission of lower priority D2D data such as D2D signaling, the D2D transmitter may use another or different RRTP (e.g., the second RRTP in Fig. 7) that may result in the usage of 19 subframes (e.g., only 19 subframes) over the same scheduling period.

[0128] A high priority RRTP (e.g., the first RRTP in FIG. 7) and / or a low priority RRTP (e.g., the second RRTP in FIG. 7) may be assigned different amounts of radio resources per time period, such as one scheduling period.

[0129] Priority handling for D2D transmissions may be improved in that, for example, for the same resource usage efficiency per D2D transmission, a lower priority D2D transmission may take longer to complete compared to a high priority D2D data transmission. The D2D transmitter device may select (e.g., autonomously select) the amount of radio resources used to transmit D2D data corresponding to, for example, the case of high priority D2D data versus low priority D2D data. A shared D2D data pool may be used, improving resource utilization and efficiency.

[0130] In FIG. 7, the time multiplexed SA and D2D data resources may be extended to frequency domain allocation for RRPTs applied to SA and D2D data pools.

[0131] Time and frequency domain allocations can be combined, for example, via radio resource transmission patterns to achieve different allocation densities over a given time period, which can be extended, as described herein, to take into account, for example, different transmission characteristics of D2D data.

[0132] The examples described herein (e.g., with respect to Figs. 6 and 7) may be extended to the case of more than two priority classes with SA or data pools in the time or frequency domain. For example, N=M=4 priority categories corresponding to four different and separate radio resource transmission patterns may be used. Different lengths of the scheduling period may be used. SA transmission may correspond to D2D data transmitted in a later scheduling period and / or in multiple scheduling periods. Independently of or in conjunction with the scheduling period, the principle of semi-persistent, time-limited or dynamically allowed D2D data transmission may be used together with the above-mentioned principle of different radio resource transmission density per time period. Although the examples used SA and D2D data for illustrative purposes, the principle of radio resource transmission density per time period may be similarly described when using different D2D channels or different signaling messages to perform priority-based access.

[0133] D2D transmission opportunities for D2D priority-based access using different Radio Resource Transmission Patterns (RRPTs) for D2D data may be advertised by a controlling device. RRPTs for use with high priority D2D data or low priority D2D data may be characterized by different allocation densities in the time / frequency domain, such as over a given time period. The controlling device may be a D2D terminal. The controlling device may be an LTE wireless network device, such as a base station.

[0134] A controlling device may signal a set of radio resources (e.g., a first set of radio resources) having a (e.g., first) radio resource allocation density over a time period for use in high priority D2D data transmissions. A controlling device may signal a set of radio resources (e.g., a second set of radio resources) having a different radio resource (e.g., a second different radio resource) allocation density over a time period for use in lower priority D2D data transmissions.

[0135] Controlling devices may signal their radio resource sets (e.g., explicitly) by using a shared control channel, such as the BCH broadcast channel or the PD2DSCH broadcast channel. System information on the BCH may include any one or both of the subframe numbers or subframe sets, or a combination of frequency resources combined or associated with access priority levels. Such D2D access and priority levels may be given (e.g., explicitly), derived (e.g., implicitly) on the order in which they may be communicated, given as part of an index list, or derived by the order in which they may be communicated.

[0136] D2D transmission opportunities for D2D priority based access may be determined by the transmitting D2D terminal in the form of separate radio resource transmission patterns (RRPTs) for D2D data, e.g., RRPTs for use with high priority D2D data or low priority D2D data may be characterized by different allocation densities in the time / frequency domain over a pre-determined time period.

[0137] A D2D transmitter device intending to transmit D2D data may determine (e.g., in advance) whether the D2D data corresponds to a high-priority data category or a low-priority data category. The D2D transmitter may determine the corresponding SA and / or data radio resources to use for its D2D data transmission, e.g., as a result of the priority determination. The D2D transmitter device may select an RRPT (e.g., a first RRPT) to be used for high-priority D2D data or an RRPT (e.g., a second RRPT) to be used for low-priority D2D data, such that the RRPT is characterized by a different allocation density in the time / frequency domain over a given time period. The D2D transmitter may transmit the SA and / or D2D data on the determined radio resources. The transmission of the SA and D2D data may terminate, e.g., when there is no more data to transmit. Re-evaluation and / or determination of the appropriate radio resources may be performed, e.g., when there is a change in the radio resources allowed for high-priority SA or low-priority SA, or when a new scheduling period begins.

[0138] A D2D receiver intending to decode D2D data may determine the SA and / or data radio resources. The D2D receiver may determine whether a high priority D2D transmission or a low priority D2D transmission may be received on the corresponding radio resource. The D2D receiver may determine a Radio Resource Transmission Pattern (RRTP) that may represent an access priority of the D2D data, such as may be indicated or decoded or derived from the D2D signal transmission. As a function of the RRTP, the D2D receiver may attempt to decode and / or demodulate at least a subset of the radio resources, e.g., as a function of the determined parameters.

[0139] Different Radio Resource Transmission Patterns (RRPTs) for D2D data using prioritized access may be determined by the transmitting D2D terminal from, for example, a timing relationship. The RRPTs for use with high or low priority D2D data may be characterized, for example, by different allocation densities in the time / frequency domain over a given time period.

[0140] For example, when reference signals are used to determine the timing parameters, these may be occurrences of timing signals and / or frequency acquisition signals such as D2DSS, DL Sync, or PD2DSCH. The transmitting D2D terminal may determine an RRPT (e.g., a first RRPT), such as a baseline pattern for occurrences of timing references. The transmitting D2D terminal may determine an adjusted RRPT (e.g., a second adjusted RRPT) to use for its D2D transmission, for example, by using the determined RRPT as an input (e.g., a first input) and a parameter of whether the D2D data is high priority or low priority as an input (e.g., a second input). The timing relationship may be performed or given via an equation that uses an index or counter representing time as one or more parameters, such as SFN. The timing relationship may be given by a bitmap or a tabulated set of values. For example, a high priority D2D transmission opportunity may be determined from a baseline RRPT pattern that results in transmission every fourth subframe starting from a measured occurrence of D2DSS from the transmitter, while a low priority D2D transmission opportunity may be determined every (e.g., only) every 12th subframe while being offset by three subframes from the first D2DSS occurrence.

[0141] The examples described herein can be extended to more than two priority classes, or to the use of different timing relationships.

[0142] The access mechanism can use guaranteed isolated resources for high priority devices.

[0143] Priority access may be performed by guaranteeing and / or potentially reserving a set of resources that can be used by higher priority data transmissions. The resources may correspond to a set of time / frequency resources (e.g., including a set of patterns) for the SA and / or data pool. Higher priority WTRUs may have guaranteed access to these resources, and lower priority WTRUs may use the high priority reserved data resources, e.g., if they are not being used by high priority data.

[0144] The SA resource pool may be segregated in time and / or frequency for different priority access WTRUs and / or data transmissions. For example, the first N SA subframes in a scheduling period may correspond to subframes that may be used by (e.g., only by) devices transmitting high priority data and / or that may be high priority devices.

[0145] The WTRU may monitor resources (e.g., SA resources / subframes) configured for transmission of data having a higher priority compared to data available at the WTRU. The WTRU may monitor subframes reserved for higher priority data transmission.

[0146] If the WTRU determines that at least X (e.g., X may be a configurable number) higher priority scheduling occurrences may be detected on higher priority SA resources (e.g., in a current or past scheduling period over a predefined window), the WTRU may transmit lower priority data on (e.g., only on) the resource pool reserved / configured for low priority data. If the WTRU determines that at least X higher priority scheduling occurrences may be detected on higher priority SA resources, the WTRU may transmit using (e.g., only on) one or more (e.g., one) of the RRPTs selected from the list of RRPTs to be used for low priority data or configured for the priority level of data available for transmission. This may mean that a lower priority WTRU may not attempt to use resources for higher priority data if there is at least one high priority data transmission. If less than X scheduling occurrences are detected, the WTRU may select resources from the data resource pools configured for higher priority data and for lower priority data. If less than X scheduling occurrences are detected, the WTRU may select from a list of RRPTs reserved for higher priority data and for lower priority data.

[0147] The WTRU may decode (e.g., first) the SA transmitted on the high priority SA resource and determine the set of resources or RRPTs used by the high priority data. The WTRU may exclude the set of resources or RRPTs used by the high priority data from the list of available RRPTs or available resources to use. This may allow a WTRU transmitting lower priority data to utilize resources that may not be used to transmit higher priority data.

[0148] Four SA subframes per 80 ms scheduling period may be configured for D2D transmission. A set (e.g., the complete set) of SA subframes 1-4 may be used for transmission and / or reception by the WTRU, for example, for high priority D2D data. A subset of SA subframes 3-4 may be used by the WTRU for low priority D2D data (e.g., only a subset of SA subframes 3-4 may be used by the WTRU for low priority D2D data). The WTRU may determine (e.g., ahead of time) whether the D2D data it has to transmit is high priority D2D data or low priority D2D data. If the WTRU determines that the D2D data is low priority, the WTRU may determine whether high priority D2D transmissions by other WTRUs are announced for the scheduling period from decoding the SAs in the four available SA subframes. If it finds such high priority SAs, it may extract the decoding information and / or determine transmission parameters corresponding to these high priority SAs. The WTRU may determine a set of D2D SAs and corresponding D2D data subframes that are currently in use by other high priority WTRUs. The WTRU may select an SA and / or D2D data resource that is not in use by the determined high priority WTRUs (e.g., all determined high priority WTRUs) and transmit its own SA. If an available SA and / or D2D data resource cannot be found, its transmission may be postponed. For example, as described above, if the WTRU determines that its D2D data is high priority, it may select an available SA and corresponding D2D data resource for its transmission (e.g., any available SA and corresponding D2D data resource for its transmission).

[0149] In one or more techniques described herein, perhaps, for example, among other scenarios, when the number of high priority WTRU transmissions decoded by a low priority WTRU is likely to be greater than some value N, the low priority WTRU may have a behavior that uses one or more of the following: Transmitting on separate SA pools and / or data pools in the same scheduling cycle Use the same SA pool, but transmit on a different data pool in the same scheduling period Use the same SA and / or data pool in the same scheduling period, but transmit using TRPT and / or time-frequency resources for SAs that may not be used by any of the high priority WTRUs. Reduce the transmit power in the current scheduling period deferring the transmission to the next scheduling cycle and / or to a random time in the future; and / or A retransmission timer is started, which in some techniques may allow the WTRU to retry one or more of the above, for example, among other scenarios, after it possibly expires.

[0150] In some embodiments, for example, with respect to SA resources, among other scenarios, SA subframes available for high priority may occur (partially or completely) earlier in time (e.g., compared to low priority SAs), possibly to avoid SA resource collisions and / or possibly to allow SA resources to be more easily accessible by high priority users. SA resources associated with high priority WTRUs and / or those associated with low priority WTRUs may be configured in the WTRU via signaling (e.g., by being assigned to different SA pools) and / or may be statically configured in one or more, or all, WTRUs.

[0151] For example, a set of SA resources configured as subframe resources and / or resource blocks for a specific transmission pool (0 <= N_PUCCH < N2) can be separated into two sets, where 0 <= N_PUCCH < N1 can be reserved for high-priority users and N1 <= N_PUCCH < N2 can be reserved for low-priority users (e.g., resources in earlier subframes can have fewer or the same N_PUCCH indices). According to this, when a high-priority WTRU transmits using a specific pool, the WTRU can randomly select and / or utilize the SA resources reserved for high-priority users (and, according to some techniques, only such resources).

[0152] A WTRU having a high priority (e.g., a first priority) can select and / or utilize any SA resources configured for D2D SA transmission in a given scheduling period. A WTRU having a low priority (e.g., a second priority) can utilize any SA resources that may not be part of the SA resources reserved for high-priority transmission. The low-priority WTRU can make such a determination by decoding the SA associated with the high-priority WTRU.

[0153] For example, a first N1-hour frequency block that can be selected by a high-priority WTRU can occur prior in time to a first N2-hour frequency block that can be selected by a low-priority WTRU (e.g., can always occur). That is, while N1 for the high-priority WTRU can be in the set 0 < N1 < K1, N2 for the low-priority WTRU can be somewhere in N1 < N2 < K2. For example, the parameters N1, N2, K1, and / or K2 can refer to a time index such as a subframe number or subframe index. A first SA pool for high-priority WTRU transmissions can be available in subframes numbered from 0 to K1 = 3. A second SA pool for low-priority WTRU transmissions can be available in subframes numbered from 0 to K2 = 8. According to this, among other scenarios, if the low-priority WTRU cannot detect high-priority WTRU transmissions in subframes N1 = 0, 1, and / or 2, it can utilize SA resources in subframes N2 > 2. For example, the parameters N1, N2, K1, and / or K2 can refer to a time-frequency index such as being identified as a numbered and / or indexed RB / subframe time-frequency resource. A first SA pool for high-priority WTRU transmissions is available in subframes numbered from 0 to K1 = 2 and in 50 RBs per subframe, and can result in one or more, or each, indexed 150 RB / subframe time-frequency resources. A second SA pool for low-priority WTRU transmissions is available in subframes numbered from 0 to K2 = 5 using 20 RBs per subframe, and can result in one or more, or each, indexed 120 RB / subframe time-frequency resources.Perhaps, among other scenarios, for example, if a low priority WTRU may not detect a high priority WTRU transmission in the 150 indexed high priority RB / subframe time-frequency resource, it may utilize the SA resource in the 120 indexed low priority RB / subframe time-frequency resource.

[0154] A WTRU with a low priority transmission may possibly use (e.g., at least a portion of) the SA resources for the scheduling period reserved for the high priority WTRU, among other scenarios, for example, after the WTRU with the low priority transmission may determine that these resources may be used. For example, if the SA (initial transmission and / or retransmission) includes at least two separate time / frequency blocks that are associated together, a WTRU with a low priority transmission may possibly use the remaining PUCCH transmissions that may belong to the high priority WTRU transmission, for example, after determining that the first PUCCH transmission may not be used. The WTRU may transmit with one or more of fewer repetitions, modified transmit power, and / or reduced MCS. A low priority WTRU may possibly utilize SA resources not reserved for the low priority WTRU, among other scenarios, for example, when it has determined that there are no transmissions by a higher priority WTRU. The decision of which selection to make may possibly be a random decision, for example, based on signaled criteria, and / or based on channel measurements.

[0155] A WTRU may apply the same or different behaviors in the examples described herein on one or more transmission pools, and possibly simultaneously in some scenarios. For example, a low-priority WTRU may possibly listen to high-priority transmissions in one or more, or multiple pools before selecting a pool to transmit in. Different pools may have different reservation rules for SA resources between high-priority and / or low-priority WTRU transmissions (e.g., pool 1 may have one or more separate SA resources for high and / or low priority, while pool 2 may not).

[0156] Using the features described herein, high priority D2D transmissions may have preferential access (e.g., first access) to configured and / or available D2D transmission resources. Low priority D2D transmissions may be selected as a function of these and may be transmitted if D2D transmission resources are still available. Given that the WTRUs may have decoded incoming SAs in SAs carrying subframes to determine whether they are able to receive corresponding D2D data as part of a monitored talkgroup, determining which D2D transmission resources are occupied using available information obtained from decoding the SAs may be obtained with little added decoding complexity.

[0157] In some embodiments, specific resources may be reserved for high priority transmissions and / or the high priority WTRU may transmit an occupancy flag indicating to the low priority WTRU that they may use the high priority SA and / or data resources for a given scheduling period. The occupancy flag may be transmitted as part of the SA (e.g., at the beginning of the SA) and / or may also be transmitted in the SA prior to the target scheduling period, possibly indicating, for example, occupancy of one or more SA resources in one or more future scheduling periods. The occupancy flag may be transmitted in a separate channel (e.g., D2DSS and / or PD2DSCH) that may be read by one or more or all D2D WTRUs. A flag may be associated with a (e.g., single) SA resource, with a pool and / or resources, and / or with one or more or all resources available for D2D transmissions.

[0158] For example, four SA subframes per 80 ms scheduling period may be configured for D2D transmission. An occupancy flag (e.g., single) associated with subframes 1 and 2 may be set whenever a high priority WTRU may utilize any of these subframes. A low priority WTRU may wish to transmit SA and / or transmit data (e.g., subsequently). The WTRU may check the presence of the occupancy flag to possibly determine, for example, whether there is a higher priority WTRU planning to transmit SA for that scheduling period. If the occupancy flag is set, the low priority WTRU may utilize subframes 3 and 4 (e.g., may utilize only subframes 3 and 4), among other scenarios. If the occupancy flag is not set, the lower priority WTRU may select any SA resource for transmission.

[0159] For example, a high priority WTRU that may have selected a resource on scheduling cycle x (e.g., and / or indicated this using an occupancy flag) may also indicate that it may reuse the same SA resource and / or data (e.g., RRPT) on a subsequent SA cycle. Notably, in such a scenario, a low priority WTRU may not use a high priority resource for, for example, the next two scheduling cycles.

[0160] A WTRU may be configured (e.g., by the eNB and / or ProSe function) and / or may be pre-configured to be enabled to transmit an occupancy flag that may be destined for low priority users. For example, a WTRU may be configured to be used by "special users" (Police Chief, Fire Chief, etc.). The WTRU may possibly transmit (e.g., be enabled to) an occupancy flag, for example, under some condition and / or trigger (e.g., emergency situation). The trigger may enable the WTRU to do so for a period of time, e.g., a finite period of time.

[0161] In some embodiments, the WTRU may measure and / or determine the signal strength and / or signal occupancy of a set of resources for the SA and / or a set of RRPTs that may be reserved for high priority data. The WTRU may possibly transmit on those resources (e.g., transmit only if), for example, the signal strength and / or signal occupancy is below some predefined and / or known threshold. The measurements may be taken at a time and / or scheduling period when the WTRU may desire to transmit, and / or they may include measurements taken in the past scheduling period and / or averaged over several past scheduling periods. The measurements may include measurements and / or RRSI, and / or similar occupancy or interference measurements. The thresholds may be statically defined and / or they may be configured in the WTRU via RRC signaling and / or via PHY layer signaling in the D2D synchronization channel (PD2DSCH).

[0162] For example, four SA subframes per 80 ms scheduling period may be configured for D2D transmission. The complete set of SA subframes 1-4 may be used for transmission and / or reception by the WTRU for high priority D2D data. A subset of SA subframes 3-4 (e.g., only such a subset) may be used for the WTRU for low priority D2D data. A WTRU may determine whether the D2D data it may wish to transmit is high priority D2D data or low priority D2D data. If the D2D data is low priority, among other scenarios, the WTRU may check the signal occupancy of SA subframes 1 and / or 2. The signal occupancy may be, for example, an averaged measurement of RSSI over the last N subframes. If the signal occupancy measurement of any of these subframes is below a threshold, a WTRU with low priority data to transmit may select that subframe for transmission. If the occupancy measurement is above a threshold, among other scenarios, a WTRU with low priority data to transmit may use subframes 3 and / or 4 for transmission. Among other scenarios, a WTRU that may determine that it has high priority D2D data to transmit may transmit using SA subframes 1 and / or 2, and / or may transmit on any of the four SA subframes.

[0163] In some embodiments, there may be different priority levels and correspondingly different SA subframes and / or different thresholds. The WTRU with the lowest priority level (e.g., of the four levels) may check occupancy measurements for one or more, or each, of the four subframes. If the occupancy level of any of the four subframes is below the corresponding threshold for that subframe, among other scenarios, the WTRU may transmit on any of the subframes whose occupancy level was below the threshold. If none of the SA subframes meets this criterion (e.g., at any time), among other scenarios, a WTRU with low priority data to transmit may postpone its transmission to the next SA period and / or repeat the described techniques.

[0164] In one or more techniques, one or more, or a set of SA and / or data resources may be reserved. A high priority WTRU may transmit at a higher power compared to a low priority WTRU, possibly when utilizing such resources, among other scenarios. A WTRU with a high priority transmission may use these reserved resources (e.g., may be restricted to using such resources). A WTRU with a high priority transmission may use one or more, or all resources, possibly while respecting a transmit power value associated with the high priority WTRU. A WTRU with a low priority transmission may use one or more, or all resources (e.g., reserved and / or non-reserved resources), possibly while respecting a transmit power value associated with the low priority WTRU. One or more techniques that allow a low priority WTRU to transmit at a lower transmit power on resources reserved for a high priority WTRU may be used in combination with other techniques described herein.

[0165] In one or more of the techniques described herein, guaranteed isolated resources for high priority WTRUs may be signaled by the network (e.g., via RRC signaling, NAS signaling, and / or MAC signaling) and / or statically determined and / or defined. They may be defined / determined by a ProSe function. The presence of guaranteed isolated resources may be dynamically determined by one or more or each WTRU, possibly based on one or more rules, and / or may not be identical for all WTRUs. For example, a low priority WTRU may possibly determine that isolated resources may be present on a given scheduling period, e.g., based on measurements made of the current and / or previous scheduling period, and / or current and / or past determinations of the presence of a high priority WTRU. For example, a low priority WTRU may possibly operate using normal Release 12 rules on scheduling periods where, for example, such a decision may indicate that no isolated resources may exist, while honoring rules associated with one or more isolated resources on those scheduling periods.

[0166] The features described herein may use specific and / or limited configurations using SA subframes, and the operating principles may be extended to D2D subframes other than SA, such as including D2D subframes and / or frequency regions allowed for D2D transmission. The features described herein may be applied for more than two priority levels, e.g., low and high, more than low, medium, and high, priority ranges, etc. The features described herein (e.g., tiered D2D transmission resources allowing a higher priority WTRU to use time / frequency resources first and allowing a lower priority WTRU to select its own D2D transmission resources in time / frequency after (e.g., only after) determining which are advertised as in use by the higher priority WTRU) may be applied to other D2D signals and / or channels other than SA.

[0167] An access mechanism for D2D control and data may be provided.

[0168] A D2D data transmission carrying control signaling may be received and / or transmitted by the WTRU on a designated set of time / frequency resources.

[0169] D2D control signaling may refer to application layer control messages exchanged between D2D WTRUs, for example to manage group calls, for floor control, session control, connection establishment, and / or similar purposes. D2D control signaling may correspond to over-the-air messages used to manage D2D connections and reception and / or transmissions at the WTRUs. The control signaling at the application layer may be a self-contained D2D PDU or it may be multiplexed with D2D data, such as carrying a VoIP packet or a segment thereof.

[0170] The set of designated time / frequency resources for transmission and / or reception of D2D control messages may be obtained from one or more of the following parameters: a timing value such as a frame counter or subframe counter, a cell-wide frame value or D2D system frame value, a timing offset value applied to a reference subframe or reference frame, an offset applied to a selected cell-wide signal or channel or occurrence of a D2D signal or channel, a frequency index in the frequency domain, an RB, or a group, a cell-wide identifier or D2D system identifier or WTRU identifier, a group communication identifier, or a channel index value or a group index value.

[0171] Some or all of the parameters may be pre-configured in the WTRU, or they may be obtained via configuration signaling during system operation, or they may be derived by the WTRU using a look-up table or formula or equivalent. The WTRU may derive the D2D transmission resources as a limited and / or specified subset of the available transmission resources, e.g., after determining the D2D subframes, allowed frequency regions, etc.

[0172] The WTRU may transmit or receive D2D control messages in a set of selected and / or reserved subframes, which may comprise a subset of the possible D2D data subframes. If a 40 ms scheduling period is used, every fourth scheduling period may include a D2D control message or signaling, for example, for one, selected, or possible one or more, or each D2D communication group.

[0173] A set of time / frequency transmission patterns may be used for transmitting and / or receiving D2D control messages. The set of transmission patterns may be predetermined and / or fixed, or it may be derived by the D2D WTRU, for example, as a function of D2D transmission parameters. If 64 possible transmission patterns are obtained following D2D data subframe allocation, the first seven of them (e.g., only the first seven of them) may be used for transmitting D2D control signaling associated with the D2D communication group. Using the features described herein, useful and / or time-critical D2D control signaling may utilize reserved D2D transmission resources in the system, for example, it may not interfere or suffer lack of transmission opportunity when D2D data such as VoIP is transmitted simultaneously in the D2D transmission resources.

[0174] A D2D transmitter device may transmit D2D data. With respect to the examples described herein, a D2D transmitter device intending to transmit D2D data may determine (e.g., determine in advance) the highest priority data available for transmission and the associated priority level of the D2D data. A WTRU may determine a priority level of a WTRU (e.g., a high priority WTRU). The D2D transmitter may determine corresponding SA and / or data radio resources to use in its D2D data transmission, e.g., as a result of the priority determination. The D2D transmitter may transmit SA and / or D2D data on the determined radio resources. The WTRU may determine D2D resources it may use, e.g., as a function of resources used by higher priority users in the system. The transmission of SA and D2D data may be terminated, e.g., when there is no more data to transmit. For example, a re-evaluation and / or determination of appropriate radio resources may occur when there may be a change in the allowed radio resources for a high priority SA or a low priority SA, or when a new scheduling period may begin, or when a time-limited grant may expire.

[0175] A D2D receiver device may receive D2D data. A D2D receiver device that intends to decode the D2D data may determine the SA and / or data radio resources. The D2D receiver device may determine whether a high priority D2D transmission or a low priority D2D transmission may be received on the corresponding radio resources. The D2D receiver device may attempt to decode one or more radio resources determined as a function of a parameter, such as a D2D service that may be received, or all radio resources, and / or a selected subset of radio resources (e.g., only such a subset). For example, if there is an ongoing high priority D2D data transmission to be received by the device, it may choose not to receive on radio resources corresponding to a lower priority SA and / or data pool, for example, if there is a receiver processing constraint. For example, if a device may be configured to receive D2D signals / channels of selected types (e.g., only certain selected types), such as low priority background service signaling, it may forgo receiving and / or processing radio resources corresponding to a high priority SA / data pool. The D2D receiver device may demodulate and / or process the D2D data transmission using the determined radio resource.

[0176] Priority-based access can utilize contention resolution for radio resources.

[0177] Priority based access for D2D communication may be achieved, for example, through the use of a persistence parameter while determining time / frequency resources for D2D transmissions.

[0178] A persistence parameter for use in prioritized D2D access can be associated with radio resources for Scheduling Assignment (SA), D2D data, control signaling or service signaling, e.g. for one or more D2D data signals / channels or D2D discovery for one or more or several D2D data signals / channels. The use of persistence parameters can be combined with different resource selection approaches such as random resource selection, channel busy mechanism or resource allocation using D2D grant.

[0179] 8 is an example diagram of priority-based access for D2D data using a persistence parameter (e.g., SA), in which the persistence parameter can be used by a D2D transmitter device with D2D data to transmit to determine whether radio resources can be used by the transmitter device and, if so, to determine SA resources that can be used for priority-based D2D data at the beginning of a scheduling period.

[0180] A D2D transmitter intending to transmit D2D data can determine a set of available SA resources. The D2D transmitter can determine which SA resources may be available by different means, such as from received configuration signaling, from pre-stored information, and / or from channel measurements. For SA resources to be considered available, the D2D transmitter can draw a random number from 0...1 for one or more (e.g., all) SA access opportunities. The D2D transmitter can compare whether the drawn random number for a given SA access opportunity is higher than a threshold (e.g., PH=0.2), such as for high priority data. If yes, it can select to transmit any high priority D2D data on the resources corresponding to the SA in that access opportunity. If the D2D transmitter has low priority D2D data to transmit, it can consider a given SA access opportunity valid if (e.g., only if) the drawn random number is higher than a threshold (e.g., PH=0.8). As a result, if the D2D transmitter determines one or more valid access opportunities, it can transmit on such selected SA access opportunities. The D2D transmitter can repeat the above for the next upcoming SA resource pool.

[0181] For example, the D2D transmitter may determine (e.g., on average) a certain number (e.g., about 60%) of SA access opportunities to be available for (e.g., exclusive) transmission of any high priority data. The D2D transmitter may determine a certain number (e.g., 20%) to be available for any low priority data and / or high priority data. The D2D transmitter may consider a certain number (e.g., about 20%) of SA access opportunities to be barred.

[0182] Use of the persistence parameter may statistically result in high priority D2D data being allowed to be transmitted (e.g., significantly) more frequently by D2D terminals than lower priority D2D data. Priority-based access for D2D communications may be improved by letting higher priority data (e.g., control signaling) and / or higher priority users win SA and / or data resource selection more frequently than lower priority users.

[0183] Figure 8 may be extended to more than two priority classes with SA or data pools. For example, persistence parameters associated with N=4 priority categories may be used. Access opportunities for D2D data transmission may be determined and / or signaled and / or interpreted from a set of time / frequency resources bounded within different subframes and / or frequency domains. The list of available resources may be obtained from prior measurements and / or channel observations. The examples described herein may be extended to persistence parameters associated with subframes and / or counters and / or indices representing time, rather than D2D access opportunities in the frequency domain. Time and / or frequency resources may not be contiguous.

[0184] The principles described herein can be similarly applied for semi-persistent, time-limited or dynamically allowed D2D data transmissions, either independently or in conjunction with one or more scheduling periods. Although the examples described herein may be used in the context of SA access opportunities, the use of persistence parameters associated with D2D access opportunities can also be similarly applied to D2D data subframes and / or to use different D2D channels or signaling messages. For example, priority-based access for D2D discovery messages rather than D2D control signaling can be determined as described herein.

[0185] Priority based access for D2D communication may be achieved, for example, through the use of a persistence parameter while determining valid time / frequency resources for D2D transmission.

[0186] It is possible for a D2D transmitter device to determine whether a D2D transmission opportunity may be granted, for example as a combination of channel measurements together with a persistence parameter. The channel measurements may be replaced by a (e.g., random) selection of a candidate D2D transmission opportunity.

[0187] The persistence parameters for use in the preferred D2D access may be advertised by a controlling device, which may be a D2D terminal, which may be an LTE wireless network device, such as a base station.

[0188] A controlling device may signal a set of persistence parameters (e.g., a first set of persistence parameters) associated with radio resources to be used for high priority D2D data transmissions. A controlling device may signal a set of persistence parameters (e.g., a second set of persistence parameters) radio resources to be used for lower priority D2D data transmissions. The persistence parameters may distinguish between different types of D2D data and / or control or service messages and may include different parameter sets for different types of signaling.

[0189] Controlling devices may signal their radio resource set (e.g., explicitly) by using a shared control channel such as the BCH broadcast channel or the PD2DSCH broadcast channel. System information on the BCH may include any one or both of the subframe number or subframe set, or a combination of frequency resources combined or associated with a persistence parameter. The persistence parameters may be given (e.g., explicitly). The persistence parameters may be derived (e.g., implicitly) on the order in which they are communicated. The persistence parameters may be given as part of an index list.

[0190] The persistent parameters used in the prioritized D2D access may be adjusted by the D2D terminal as a function of, for example, one or more of the following: observed signal conditions, channel measurements, sensing of transmission collisions and / or interference, detection of a transmission by a higher priority WTRU, timing and / or counter values ​​(e.g., based on data latency requirements), and / or signaling events.

[0191] A transmitting D2D terminal may determine (e.g., in a first instance) that no D2D access opportunity may be allowed, e.g., as a result of a persistence check. The transmitting D2D terminal may postpone its D2D transmission attempt until a later (e.g., second) time. The D2D transmitter may reduce the threshold for low priority access to a lower value (e.g., to PL=0.7). This may be the case, for example, if some conditions are met (e.g., based on signal conditions, timing or counter values, signaling events, etc.). If during a later (e.g., second) time instance it still fails to transmit its low priority data, it may reduce the threshold to a lower value, e.g., to 0.6. If at a later time instance (e.g., a third), it successfully transmits low priority D2D data, the D2D terminal may reset the threshold to an initial value, e.g., PL=0.8, for any (e.g., subsequent) initial attempts to transmit low priority data.

[0192] The persistence parameters may be adjusted by the D2D transmitter as a function of, for example, one or more (e.g., one) of the following events or observations: successful or unsuccessful access attempts, available absolute or relative D2D traffic volume in a queue, timer or counter values ​​at expiration (e.g., for delay-sensitive traffic or to meet latency requirements), or as a function of preceding D2D data transmission or reception events, received signal strength of signals or channels received from other D2D terminals or LTE infrastructure nodes, etc. The adjustment of persistence parameters by the D2D terminal can occur separately for different types of D2D data, such as a set of persistence parameters (e.g., a first set of persistence parameters), a set for D2D high priority data (e.g., a second set for D2D high priority data), a set of persistence parameters (e.g., a third set of persistence parameters), which are adjusted as a function of signal conditions, events, or timer / counter conditions, etc., related to D2D discovery.

[0193] The persistence parameters applicable to a type of transmission for a D2D terminal can be adapted as a function of characteristics of received D2D signals, for example transmitted by other terminals. Such signals may or may not be directed to the D2D terminal adapting the persistence parameter. The characteristics may include one or more of the following: suitability possibly related to the number of D2D transmissions received over a period of time, from a particular channel (e.g., PSCCH or PSSCH), or a priority level associated with at least one received D2D transmission.

[0194] The WTRU may reduce the persistence parameter applicable to the type of transmission, for example, if it has received at least one D2D transmission (or an SA associated therewith). The received D2D transmission may have to satisfy at least one of the following conditions: the priority level of the received D2D transmission may have to be higher or equal to the priority associated with the type of transmission, the received D2D transmission may have to be received possibly not more than a certain duration after the last received D2D transmission of the same or higher priority, the group destination ID, source ID or destination ID associated with the received D2D transmission may have to match a certain value, the resource (e.g., resource pool) on which the D2D transmission was received may have to match one of the set of resources, such as resource pools, associated with the type of transmission for which the persistence parameter is applicable.

[0195] The priority level of a received D2D transmission may be obtained from one or more of the following: a field included in the sidelink control information (e.g., in the PSCCH) such as an explicit indication of priority, or a field in the MAC header of the transport block decoded from the PSSCH, such as a group destination ID, an explicit indication of priority, or a source or destination identity associated with the priority level, which may be associated with the priority level; the resource on which the D2D transmission was received (e.g., a resource pool and / or T-RPT).

[0196] For one or more, or each received D2D transmission, the persistence parameter may be reduced by a first step size. The persistence parameter may be increased by a second step size (e.g., which may typically be smaller than the first step size) at regular intervals such that its value is progressively restored to a higher level, e.g., in the absence of received D2D transmissions. The WTRU may periodically determine the value of the persistence parameter based on the number or density of received D2D transmissions (or equivalently, SAs) over the past evaluation period, or equivalently, based on an estimated load on the D2D resources (e.g., based on an estimated average SINR, or otherwise).

[0197] The WTRU may receive the value of the persistence parameter from a field in the PSCCH or PSSCH of the received D2D transmission and may apply this value if it is lower than the current value and / or until expiration of a timer that is started when this transmission is received.

[0198] The persistence parameter may be constrained to be within a defined range, for example, such that it cannot fall below a certain value (or increase above a certain value) even if one of the aforementioned conditions is met.

[0199] The supporting parameters can be configured, predefined, or preconfigured by higher layers, and may include, for example, one or more of a step size, an interval, a duration of an evaluation period, a persistence value (e.g., possibly for one or more, or each value of the received field, if applicable), a corresponding interval, or a minimum and maximum value for the number of transmissions received within an evaluation period.

[0200] Characteristics of the received D2D signal described herein may determine the selection of a resource pool among the set of candidate resources (e.g., this may be in addition to the persistence parameter). For example, the WTRU may select a resource pool that maximizes or minimizes a certain metric, which may be a function of the received D2D transmissions on the resource pool. The metric may be evaluated in a similar manner as described herein with respect to the persistence value (e.g., lower if the number of received D2D transmissions in a period of time is higher).

[0201] The persistence parameters applicable to a type of transmission for a D2D terminal may be adjusted as a function of characteristics of a received D2D signal transmitted by one or more other terminals. Such signals may or may not be directed to the D2D terminal adapting the persistence parameter. The characteristics of the received D2D signal may possibly include one or more of a characteristic related to the number of D2D transmissions received over a period of time from a particular channel (e.g., PSCCH or PSSCH) or a priority level associated with at least one received D2D transmission.

[0202] One or more persistence parameters may be adjusted based on the received D2D transmission. For example, a WTRU may reduce a persistence parameter applicable to a type of transmission if it has received at least one D2D transmission. The received D2D transmission may have to satisfy at least one of the following conditions: the priority level of the received D2D transmission may have to be higher than or equal to a priority associated with the type of transmission, the received D2D transmission is received not more than a certain duration after the last received D2D transmission (e.g., of the same or higher priority), a group destination ID or a source ID or destination ID associated with the received D2D transmission matches a certain value, and the resource (e.g., resource pool) on which the D2D transmission was received matches one of a set of resources, such as a resource pool, associated with the type of transmission for which the persistence parameter is applicable.

[0203] The priority level of a received D2D transmission may be obtained from one or more of the following: a field included in the sidelink control information (e.g., in the PSCCH) such as an explicit indication of priority, or a field in the MAC header of the transport block decoded from the PSSCH, such as a group destination ID, an explicit indication of priority, or a source or destination identity associated with the priority level, the resource on which the D2D transmission was received (e.g., a resource pool and / or T-RPT).

[0204] One or more persistence parameters may be adjusted based on the received D2D transmission. One or more of the following examples may apply.

[0205] When a D2D transmission is received, the persistence parameter may be reduced by a first step size (e.g., this may occur one or more times, or each time a D2D transmission is received). The persistence parameter may be increased by a second step size (e.g., which may typically be smaller than the first step size) at regular intervals such that its value may be gradually restored to a higher level in the absence of a received D2D transmission.

[0206] The WTRU may periodically determine the value of the persistence parameter based on the number of received D2D transmissions over a past evaluation period.

[0207] The WTRU may receive the value of the persistence parameter from a field in the PSCCH or PSSCH of the received D2D transmission and may apply this value if it is lower than the current persistence parameter value. The value may be maintained until expiration of a timer that is started when the transmission is received.

[0208] The persistence parameter may be constrained within a defined range, e.g., the persistence parameter is not allowed to fall below (or increase above) a certain value, even if one of the aforementioned conditions is met.

[0209] The supporting parameters can be configured, predefined, or preconfigured by a higher layer, and may include, for example, at least one of a step size, an interval, a duration of an evaluation period, a persistence value (e.g., for one or more, or each value of a received field, if applicable), a corresponding interval, or a minimum and maximum value for the number of transmissions received within an evaluation period.

[0210] Characteristics of the received D2D signal described herein may determine the selection of a resource pool among the set of candidate resources (e.g., this may be in addition to the persistence parameter). For example, the WTRU may select a resource pool that maximizes (or minimizes) a certain metric, which may be a function of the received D2D transmissions on the resource pool. The metric may be adjusted as described herein with respect to the persistence value (e.g., lowered if the number of received D2D transmissions in a period of time is higher).

[0211] The priority based access may include persistent radio resources.

[0212] Priority based access for D2D communication may be achieved via persistent radio resource allocation for high priority D2D channels or high priority signals or high priority users.

[0213] Persistent radio resource allocation may refer to the use of radio resource transmission opportunities that may be held by a D2D terminal for a pre-determined and / or pre-configured duration, such as the duration of a high priority D2D transmission and / or beyond a single scheduling period. Persistent radio resource allocation may be characterized by the ability of a D2D terminal to hold an acquired radio resource for an extended period of time without reselecting a D2D transmission opportunity, such as when it determines access to a D2D radio resource via a channel selection mechanism with which it initiates its high priority D2D channel and / or D2D signal transmission. A channel selection mechanism may refer to a random selection of radio resources, such as a subframe and RB combination, for example. A channel selection mechanism may refer to a measurement-based radio resource selection, such as a set of at least interfered RBs in a subframe. Channel selection may refer to resource allocation via another device, such as an eNB.

[0214] A D2D terminal intending to transmit a high priority D2D voice group channel may determine allowed D2D subframes, for example, from information pre-stored in the device. The pre-stored information may include a set of allowed subframes (e.g., a first set of subframes) for transmission of an allowed SA and / or a set of subframes (e.g., a second subframe) for use with D2D data over a given transmission period. The D2D terminal may perform channel selection via measurements on the SA subframes to determine suitable, at least interfered, transmission opportunities for its SA. The device may select one or more (e.g., two) PRBs in the SA subframe for transmission of its SA. Channel selection via measurements that determine at least interfered resources may imply postponing transmission to a later time, such as when the D2D terminal may not identify a suitable (e.g., non-interfered) transmission opportunity. The D2D terminal may transmit D2D data associated with this SA over a corresponding scheduling period, for example, once the D2D terminal starts transmitting an SA. The location of the corresponding D2D data in a subframe and the RBs included within the subframe portion of the scheduling period can be indicated via a radio resource transmission pattern (RRTP). The RRTP can be included in the SA, for example, as part of its payload, or it can be given via the time / frequency location of the SA, or a combination thereof. The D2D terminal can be allowed to keep the radio resources it acquired (e.g., versus relinquishing those resources) and re-perform channel selection on the SA and / or the corresponding D2D data resources, for example, after the scheduling period ends. The D2D terminal can avoid channel selection and / or any ongoing high priority D2D transmissions can not be interrupted. Priority-based access can be enhanced (e.g., statistically) such that high priority D2D channels can not compete for access to resources.High priority D2D channels may compete for resources at the start of a transmission. Long (e.g., long enough) high priority D2D transmissions may utilize guaranteed access to D2D radio resources, e.g., after having been obtained, such as on the order of several more scheduling periods. High priority D2D data transmissions may be improved, for example, in that they may not be interrupted during an ongoing transmission due to channel selection.

[0215] A D2D terminal that selects a D2D transmission opportunity in a time period (e.g., a first time period) may retain the acquired radio resources in a time period (e.g., a second time period) if, for example, it may have high priority D2D data to transmit.

[0216] For example, a D2D terminal may have selected to transmit SA in RBs 3-4 of subframe 1 in SFN 1. Transmitting associated D2D data in selected subframes from SFNs 1-16 may continue to use the same or similar SA transmission opportunities, such as in RBs 3-4 of SFN 17 over the next scheduling period.

[0217] The examples described herein may be extended to suit specific D2D data characteristics. For example, the RRPT of a transmission period (e.g., a first transmission period) may determine the RRPT of a subsequent transmission period. Persistent use of a D2D transmission opportunity may be indicated by the D2D terminal, for example, as part of its D2D data and / or control signaling. Such an indication may be realized via a portion of the payload, such as provided by the SA information field, or via selection of sequence coding parameters or initialization values ​​or settings, or via a specific signaling format in one or more, or all, of the transmission periods.

[0218] A D2D terminal that may have selected a D2D transmission opportunity at time T1 may hold the selected D2D radio resource for a predetermined amount of time before reselecting the D2D transmission opportunity.

[0219] For example, a D2D terminal choosing to transmit SA in RBs 3-4 of subframe 1 in SFN1 may hold radio resources for a duration of 3.2 seconds.

[0220] A D2D service access class may be described herein.

[0221] D2D terminals may store as part of their D2D related configuration the D2D service access class information related to the D2D data they are capable of supporting.

[0222] The D2D access class information may correspond to any type of parameter used to support priority-based access for D2D data transmissions. The D2D access class for a given terminal may correspond to the D2D and / or public safety services it may support.

[0223] The D2D terminal may support (e.g., may only support) file uploads and / or file downloads. The D2D terminal may not support the public safety voice call group, such as it may not support audio applications. The D2D terminal may support (e.g., may only support) the exemplary D2D service access class 3 and may use (e.g., use only) any advertised low priority D2D access opportunities.

[0224] The D2D terminal may support public safety voice groups and / or file uploads or downloads. The D2D terminal may support exemplary D2D service access classes 2 and / or 3 and / or may use high priority and / or low priority D2D data access opportunities.

[0225] A D2D terminal may support voice (e.g., voice only) and may be reserved for use by staff in the chain of command or for a voice call group. A D2D terminal may support (e.g., exemplary) D2D service access class 1 for the highest emergency type of voice calls and / or class 2 for high priority D2D data access opportunities.

[0226] The D2D service access class may be associated with stored configuration information that allows establishing different types of allowed D2D services in the D2D terminal.

[0227] The D2D service access classes stored in a D2D terminal may be used by the D2D terminal in conjunction with the channel access parameters obtained from the signaling to determine the allowed D2D time / frequency radio resources. For example, a D2D terminal supporting high and low priority D2D data transmissions with stored D2D service access classes 2 and 3 may read D2D related configuration information from the DL broadcast channel, it may configure its transmitter as a function of the decoded signaling parameters (e.g., as described herein) for these classes, and it may discard and / or ignore the information obtained with the highest priority advertised D2D service class 1, which it may not support.

[0228] A D2D service access class in a D2D terminal may be associated with a set of stored channel access parameters for D2D prioritized access.

[0229] For example, a set of D2D subframes allowed for SA transmission at a time (e.g., a first set of allowed D2D subframes) may be associated with a D2D service access class, e.g., in the form of a database or index table entry. A set of persistence parameters (e.g., a first set of persistence parameters) may be stored in the D2D terminal associated with a D2D service class (e.g., a first D2D service class) such as public safety voice. A set of persistence parameters (e.g., a second set of persistence parameters) associated with a D2D service class (e.g., a second D2D service class) such as file upload or file download may be stored in the D2D terminal.

[0230] D2D transmission and / or D2D reception may be disclosed. The D2D transmission and / or D2D reception may include priority handling.

[0231] A WTRU may transmit an indication that access to at least one resource is desired for transmission of some voice or data traffic. Such an indication may be referred to as a desired access indication as described herein. Such an indication may be provided via use of a preemption indication as described herein. A WTRU that receives such an indication may interrupt an ongoing transmission and / or refrain from accessing the resource for a period of time. The received indication may be provided to a higher layer (e.g., an application layer). This may indicate to an end user that another user desires access to the resource.

[0232] One or more triggers for the transmission of a desired access indication may be provided. The WTRU may initiate the transmission of a desired access indication based on one or more of the following:

[0233] An application may request a triggered transmission of a desired access indication. Such a request may originate from an end user, for example, via a user interface. For example, one or more of the following may apply: An end user may press a specific key or button on a device used for voice or data transmission, for example, in an emergency situation. The transmission of a desired access indication may be triggered by a voice emotion recognition application detecting an emotion consistent with an emergency situation. The transmission of a desired access indication may be triggered if the WTRU determines that one or more available resources (e.g., all available resources) are utilized for transmissions from other WTRUs. The indication may be triggered if (e.g., only if) a detected transmission from another WTRU is at a lower priority level.

[0234] Transmission of a desired access indication may be triggered if (e.g., only if) the WTRU determines that no other WTRU may have transmitted a desired access indication that may still be valid. If a priority level is indicated as part of the desired access indication, such a condition may apply if (e.g., only if) an indication that may be transmitted by another WTRU indicates a priority (e.g., higher or equal priority) compared to the indication that is to be triggered. Possible conditions that determine whether a received indication is valid may be described herein.

[0235] The desired access indication may include one or more of the following. The WTRU may include one or more (e.g., at least one) of the following as part of the message containing the indication: Identification of the WTRU. A value identifying traffic to which the one or more indications may relate ("traffic identification information"). For a transmitted indication (e.g., a first transmitted indication) related to a given traffic, such a value may be selected (e.g., randomly selected) from a subset of possible values ​​that may not be used by other indications. For an indication (e.g., a subsequent indication), the value may be set to the same or a similar value in other indications (e.g., previous indications) related to the same or similar related traffic. One or more (e.g., at least one) characteristics of the traffic related by the indication, such as priority level, duration, expected duration, amount of data, data rate, transmit power level, application, service, etc. One or more (e.g., at least one) identifiers of resources to which the indication may be applied. The WTRU may be set to one or more (e.g., at least one) identifiers identifying resources related by the indication. A period of time (e.g., or delay) before the associated traffic may start to be transmitted and / or before the indication may be retransmitted. This value may correspond to the duration of a wait timer. For example, an indication that, upon expiration of the delay, the associated traffic may start to be transmitted or the indication may be retransmitted.

[0236] The transmission of a desired access indication may be described herein. The desired access indication may be encoded and / or transmitted on a physical channel used for control purposes, such as PD2DSCH. The indication may be transmitted using the same or similar type of transport or physical channel as normal traffic, e.g., using a specific resource for the indication or one or more of a set of reserved resources, as the case may be. The indication may be included as part of the scheduling assignment and / or may be transmitted within the set of resources used for transmission of the scheduling assignment. The indication may be transmitted in multiple instances for added robustness.

[0237] After transmission of the desired action indication, an action may be taken. After transmission of the indication and / or after completing transmission of the indication, the WTRU may start a timer (e.g., referred to herein as a “wait timer”) whose duration may correspond to a time (e.g., last) at which the WTRU may start transmitting the associated traffic and / or retransmit the indication. The WTRU may monitor one or more (e.g., at least one) available resources to detect whether it is available and / or whether one or more (e.g., at least one) other WTRUs may be transmitting on the resource. A valid resource may correspond to one or more (e.g., one) of a set of resources configured to be available for transmission of traffic that may be associated with by the desired access indication. The WTRU may consider a resource to be valid if (e.g., only if) it may be associated with a priority level equal to or lower than the priority level of the associated traffic.

[0238] The WTRU may, for example, stop the wait timer after detecting that one or more (e.g., at least one) resources may be available for transmission of the associated traffic. The WTRU may start transmission of the associated traffic on the one or more (e.g., at least one) resources.

[0239] After the wait timer expires, the WTRU may perform one or more (e.g., at least one) of the following actions: The WTRU may resume transmitting the indication and / or restart the wait timer. The WTRU may start transmitting the associated traffic on the valid resource if it detects or does not detect other WTRUs transmitting on this resource. After starting transmission of the associated traffic, the WTRU may start a timer (referred to herein as a "keep alive" timer).

[0240] After selection of resources for transmission of the associated traffic, the WTRU may begin transmitting a selected resource indication, e.g., to indicate to other WTRUs which resources have been selected. This may enable the other WTRUs to resume transmission on resources not used by the WTRU. The selected resource indication may include one or more (e.g., at least one) resource identifiers (e.g., indexes) and / or a duration or minimum duration for the use of the resources. The selected resource indication may be the same as or similar to a desired resource indication, e.g., with a signaled value for the resource identifier that may differ from the transmitted (e.g., previously transmitted) desired resource indication.

[0241] The WTRU may initiate transmission of a subsequent desired access indication and / or transmission of a selected resource indication, for example, after expiration of the keep-alive timer if it determines that there may still be traffic related to the desired access indication that may be transmitted. The keep-alive timer may correspond to or be the same as or similar to the wait timer.

[0242] A release indication may be transmitted. Release indication transmission may be disclosed herein. The WTRU may trigger transmission of a release indication and / or stop a keep-alive timer, for example, when traffic related to a desired access indication transmitted (e.g., previously transmitted) may no longer be present. Such a determination may be performed using mechanisms similar to those described herein that may be used to trigger a desired access indication based on higher layers. The maximum duration for transmitting traffic related to the desired access indication may be configured by higher layers or otherwise. The release indication may include traffic identification information corresponding to the related traffic. The release indication may be encoded and / or transmitted on the same physical channel as the desired access indication.

[0243] After receiving the desired access indication and / or selected resource indication, actions may be taken: The WTRU may monitor one or more (e.g., at least one) physical channels on which other WTRUs may transmit desired access indications, selected resource indications, and / or release indications.

[0244] After receiving a desired access indication, the WTRU may perform one or more (e.g., at least one) of the following actions: The WTRU may take the indication into account for (e.g., only for) traffic that may have a priority lower than or equal to the priority level signaled by the received indication. This may be referred to herein as "non-prioritized traffic." The WTRU may stop running wait and / or keep-alive timers associated with the received (e.g., previously received) indication, e.g., that includes the same or similar traffic identity parameters. The WTRU may start or restart a wait timer with a duration whose value may be included in the received indication.

[0245] After receiving a selected resource indication, the WTRU may stop any running wait timers and / or keep-alive timers associated with the received indication (e.g., a previously received indication), e.g., including the same or similar traffic identification parameters, and may start or restart a keep-alive timer with a duration that may be included in the received indication. The indication may be sent to a higher layer, such as an application layer or a user interface, e.g., to inform an end user that another user may be attempting to access the resource. Such an indication may be visual (e.g., a light indicator), audible, or tactile (e.g., vibration).

[0246] The WTRU may determine whether it is transmitting (e.g., currently transmitting) non-prioritized traffic on one or more (e.g., at least one) resources related by the indication. The set of resources related by the indication, if present, may correspond to one or more (e.g., at least one) values ​​included in the indication. The set of resources may correspond to resources associated with a priority level that may be equal to or lower than the priority level included in the indication. The WTRU may stop (e.g., immediately stop) transmission of non-prioritized traffic on such resources. The WTRU may stop transmission, for example, at the beginning of the next scheduling period and / or upon expiration of a wait timer. The interruption of traffic transmission on a resource may occur if (e.g., only if) another resource may be available or if the indication may not be transmitted to the application layer or user interface.

[0247] While a wait timer or keep-alive timer associated with a received (e.g., previously received) indication may be running, or after receipt of a selected resource indication, the WTRU may select one or more (e.g., at least one) resources, which may not be part of the set of resources concerned by the indication, for transmitting non-prioritized traffic and / or for starting transmission of non-prioritized traffic.

[0248] Actions may be taken after receiving a release indication and / or expiration of a keep-alive timer. After receiving a release indication, the WTRU may stop any timers (e.g., wait timers or keep-alive timers) associated with the received (e.g., previously received) indication, e.g., including the same or similar traffic identity parameters. The WTRU may determine, e.g., that no traffic may be deprioritized with respect to the traffic identity that may be included in the release indication. After expiration of the keep-alive timer, the WTRU may determine, e.g., that no traffic may be deprioritized with respect to the traffic identity that may be included in the associated release indication (e.g., a timer may have been started after receiving it).

[0249] Preemption can take advantage of D2D prioritized channel access.

[0250] Preemption indication may be explicit. Explicit preemption indication and physical handling of preemption indication may be described herein. In a distributed scheduling D2D system, there may be no controlling entity that ensures that high priority messages get access to resources on time. Preemption may be a mechanism that may be used by a device, for example, to interrupt (e.g., temporarily interrupt) an ongoing communication from another device so that resources may be freed up for its own use.

[0251] Preemption may be motivated when resources may be constrained and / or one or more, or each resource may be utilized (e.g., currently utilized), such as when a WTRU transmits a high priority message. Preemption may be used when resources for a group of users (e.g., or other classification) may be occupied and / or a higher priority signal for that group may be transmitted (e.g., other radio resources are available and may be reserved for other user groups).

[0252] A D2D WTRU may be configured to transmit a preemption indication. The indication may consist of a message and / or may convey a certain amount of information. The indication may consist, for example, of a signal from which the amount of information (e.g., a limited amount) may be inferred.

[0253] A message-based indication may be described herein. A D2D WTRU may be configured to transmit a message-based preemption indication. The preemption message may carry one or more of the following information in any order or combination: resource index, identity, priority level, amount of time to back off, interruption cause, and / or T-RPT. The preempting WTRU may indicate a particular resource index, which may be selected from a list of resources used (e.g., currently being used). The transmission associated with that resource may be interrupted regardless of the identity of the user transmitting (e.g., currently transmitting) on ​​the resource. The identity may be used to indicate a target WTRU identity and / or group identity to be preempted (e.g., which user / target group may stop transmitting). A priority level may be associated with the preemption message and / or of the data transmission. The WTRU may indicate a priority level associated with its transmission, e.g., so that a WTRU with a lower priority may stop transmitting. The amount of time the preempted WTRU may interrupt its transmission. After the backoff time expires, the preempted WTRU may be allowed to resume transmission. The interrupt cause may be the cause of the preemption. For example, the cause may be selected from a finite list including, for example, emergency call, relaying, etc. The T-RPT may be the preempting pattern index. The WTRU may indicate (e.g., explicitly) the resources it may want to interrupt.

[0254] The WTRU may be configured to transmit the preemption message over a Scheduling Assignment (SA). The WTRU may be configured to use a special identifier in the SA that indicates that the SA may be associated with the preemption message. The WTRU may transmit the preemption message over the SA, for example, as a control signal.

[0255] The preemption message may be carried directly in the SA, thus replacing the existing field of the SA. The WTRU may transmit the preemption message using the SA format using a reserved SA pool. D2D WTRUs transmitting data may be configured to monitor the preemption resource pool to determine whether their transmissions may be preempted. A WTRU receiving a preemption message may be configured to determine (e.g., blindly determine) whether the received SA may be a conventional SA or a preemption message. The WTRU may make this determination, for example, based on (e.g., blindly) a CRC appended to the SA and / or the preemption message. The preemption message portion may be carried in the data associated with the SA. For example, the preemption message may be carried via a MAC Control Element (CE).

[0256] The WTRU may be configured to transmit a preemption message on the PUCCH resource.

[0257] This PUCCH resource may be associated with the D2D transmission. The association may be done, for example, based on characteristics of the SA associated with the transmission that the WTRU may want to interrupt. For example, the WTRU may be configured to transmit a preemption indication at a known time, e.g., after the SA is transmitted and / or at a particular PUCCH location in frequency, e.g., based on the SA resources that may be used.

[0258] The WTRU may transmit the preemption message using a signal format. The WTRU may be configured to transmit the preemption message in time / frequency resources that may be reserved for preemption.

[0259] The WTRU may be configured to transmit and / or receive preemption messages on (eg, only on) a specified set of time / frequency resources.

[0260] The set of designated time / frequency resources for transmission and / or reception of the preemption message may be obtained from one or more of the following: a timing value such as a frame counter or subframe counter, a cell-wide frame value or D2D system frame value, a timing offset value applied to a reference subframe or reference frame, an offset applied to a selected cell-wide signal or channel or occurrence of a D2D signal or channel, a frequency index in the frequency domain, an RB, or a group, a cell-wide identifier or D2D system identifier or WTRU identifier, a group communication identifier, or a channel or group index value.

[0261] Some or all of the parameters may be pre-configured in the WTRU, or they may be obtained via configuration signaling during system operation, or they may be derived by the WTRU using a look-up table or formula or equivalent.

[0262] The WTRU may transmit or receive a preemption message in a set of selected and / or reserved subframes, which may comprise a subset of possible SA subframes. For example, if the SA is configured over an 80 ms scheduling period, every fourth occurrence of an SA subframe for a particular scheduling period may contain a preemption message. In this case of a shared resource where both SA and preemption messages may exist, the WTRU may distinguish, via decoding, whether a particular time / frequency resource contains an SA or a preemption message.

[0263] The WTRU may be configured with a set of D2D subframes not used for SA or D2D data that it may use to transmit and / or receive preemption messages. For example, if the SA is configured for a scheduling period of 40 ms, the preemption message may be transmitted or received in a designated D2D subframe that is reserved for that purpose every 80 ms and may not otherwise be used, for example, for SA or data transmission. For this case where dedicated time / frequency resources are used for preemption messages, the WTRU may detect (e.g., only need to detect) a single transmission format.

[0264] The WTRU may transmit and / or receive a preemption message in a subset of D2D data frames. The SA may announce the D2D data over a scheduling period, while the set of D2D data subframes may include control signaling carrying the preemption message. The WTRU may determine the presence and / or absence of a preemption message on the set of D2D subframes by decoding the selected signaling format.

[0265] The WTRU may transmit or receive a preemption message in one or more limited frequency regions, which may be selected from a set of possible D2D subframes used for control or data. The WTRU may decode for the presence of a preemption message or transmit a preemption message on (e.g., only on) a selected set of RBs (e.g., 1-10) in subframes configured for SA. The allowed set of RBs may be known to the WTRU and / or derived from the RB index.

[0266] A signal-based representation may be described herein.

[0267] The WTRU may be configured to transmit a signal as a means for preemption indication, for example, which may consist of a signal taken from a predefined list of sequences, for example, based on the Zadov-Chu sequence.

[0268] While the preemption signal itself may not carry any information (eg, explicit information), an indication (eg, implicit indication) may be inferred from reception of the signal by the receiving WTRU.

[0269] A receiving WTRU may determine information from the preemption signal, for example, based on the signal, time / frequency transmission, and / or other index. The preemption signal may be transmitted on a set of PRBs that may be associated with an ongoing transmission that it is to preempt using a known set of rules. The WTRU may be configured to transmit the preemption signal on a set of PRBs associated with an SA associated with a transmission that it may want to preempt.

[0270] The WTRU may be configured to select a preemption signal (or parameters for generation of a sequence) from a predefined list based on, for example, one or more of the following: a priority level of the transmission; a WTRU identifier (e.g., RNTI, IMSI, or other); a group communication identifier; a transmission pattern index, which may be a transmission pattern associated with the transmission that the WTRU wants to preempt.

[0271] The WTRU may base the selection of the preemption signal on one or more of the factors described herein.

[0272] It may be determined when to transmit a preemption indication. The WTRU may be configured to determine the conditions for when to transmit a preemption indication. The WTRU may be configured to determine to transmit a preemption indication based on, for example, one or more of the following triggers (in any order or combination): The WTRU may have data to transmit. The WTRU may be configured and / or allowed to use preemption. The data to transmit may be associated with a logical channel / bearer / QoS / QCI for which preemption may be allowed and / or configured. The WTRU may receive a command to start / stop preemption from a higher layer (e.g., RRC). A data packet to be transmitted may be associated with a request for preemption transmitted by a higher layer (e.g., MAC). The WTRU may have determined, for example, based on measurements or monitoring of SAs, that there may not be radio resources available for transmitting its data. The WTRU may have determined that there are one or more (e.g., at least one) resources that can be (e.g., currently) used and / or that can be preempted. The WTRU may be configured to determine a priority level of the or each data transmission, for example, based on the SAs it can receive. The WTRU may be configured to determine for one or more or each received SA and / or for one or more or each received transmission whether it can be preempted. This may be performed, for example, based on one or more of absolute priority, a transmission source identity, a target identity for the transmission, etc. For example, the priority of the data to be transmitted may be higher than one or more (e.g., at least one) ongoing transmissions. The priority of the WTRU may be higher than the priority of one or more (e.g., at least one) other WTRUs that are transmitting data.The priority of a target group may be higher than the priority of one or more (eg, at least one) other target groups to which data may be being transmitted.

[0273] The WTRU may take action after receiving a preemption indication. A D2D WTRU transmitting data may be configured to monitor for potential preemption indications. The WTRU may be configured to receive preemption indications at reserved and known time / frequency locations and / or may be configured to receive preemption indications in the SA.

[0274] The WTRU may decide whether or not to act on the received preemption signal.

[0275] If the WTRU is able to determine that it is receiving a preemption indication, the WTRU may be configured to determine whether it is able and / or may desire to operate according to the preemption indication. The WTRU may be configured to determine whether it is able and / or may desire to operate according to the received preemption indication, for example, based on one or more of the following: A priority level that may be associated with the preemption indication (e.g., an explicit preemption priority level, a priority level associated with the transmitter of the preemption indication, a priority level of the target group, etc.); A target WTRU that may be associated with the preemption indication. For example, the preemption indication may carry information indicating a target transmitter / transmission that is to be interrupted. The WTRU may be configured to determine whether it is the target of a preemption indication based, for example, on the contents of the preemption message (e.g., transmitter identifier, group identifier, specific resource identifier, priority level, etc.) or based (e.g., implicitly) on the time / frequency / signal characteristics of the preemption signal.

[0276] Preemption applications may be described herein.

[0277] The WTRU may act according to a preemption indication received by the WTRU and may be configured to release resources that may be preempted. After detection of a preemption indication from which it may determine that it may be able and / or willing to act accordingly, the WTRU may be configured to perform, for example, the following: The WTRU may stop data transmission. The WTRU may release resources. The WTRU may be configured to stop transmission in the SA. The WTRU may be configured to transmit a resource release indication. For example, the WTRU may be configured to transmit a special end indication in the SA indicating (e.g., optionally indicating) the cause of the transmission end (e.g., preemption). The WTRU may be configured to start a back-off timer (e.g., of a predefined value). The WTRU may not be allowed to resume data transmission and / or attempt to transmit data until, for example, the timer expires. After preemption may be completed and / or the preemption timer expires, the WTRU may be configured to reinitialize the transmission (e.g., re-evaluate transmission parameters) as if it were a new (e.g., fresh or updated) transmission.

[0278] The WTRU may be configured to "hold" resources for the duration of the preemption interruption. The WTRU may be configured to transmit an indication of holding resources. For example, the WTRU may be configured to transmit an indication in the SA indicating resource reservation (e.g., "channel reserved") that indicates (e.g., optionally indicates) the cause of the resource reservation (e.g., preemption). The WTRU may be configured to start a back-off timer (e.g., of a predefined value). The WTRU may not be allowed to resume data transmission and / or attempt to transmit data until the timer expires. After the preemption is complete and / or the preemption timer expires, the WTRU may be configured to resume transmission using the same resources that were preempted. The WTRU may be configured (e.g., optionally configured) to resume transmission (e.g., only resume) using the same or similar resources if, for example, it resumes transmission within the same or similar scheduling period. The WTRU may be configured to indicate to higher layers the receipt of a preemption indication that it may be able and / or may wish to act accordingly. For example, the WTRU may be configured to indicate to higher layers when a channel may be busy and / or the WTRU may be pending transmission. The WTRU may be configured to indicate to higher layers when it may fail to transmit data due to preemption. This may be relevant for delay-sensitive applications where data may be discarded after some time has passed. The WTRU may indicate to higher layers when the duration of an interruption due to preemption may be longer than a certain predefined duration.

[0279] The D2D terminal may be utilized to perform prioritized channel access.

[0280] Transmit and / or receive half duplex may be priority-based access utilized. It is possible for a D2D terminal to process multiple D2D channels / signals that are to be transmitted and / or received based on the priority of the D2D channels and / or signals.

[0281] A receiving D2D terminal may have multiple simultaneous D2D channels and / or signals to receive and / or transmit. Based on the priorities for these D2D channels or signals, it may adjust its reception and / or transmission schedule to allow prioritized reception (e.g., or transmission) of high priority D2D channels / signals.

[0282] 9 is an example diagram of prioritized reception of a high priority channel by a D2D terminal having FDD half-duplex operation, in which a D2D terminal may have a high priority D2D voice channel (e.g., a first high priority D2D voice channel) to receive, such as for a voice group call, while (e.g., simultaneously) it may have a lower priority D2D data channel (e.g., a second lower priority D2D data channel), such as for a file upload to transmit.

[0283] In FIG. 9, talk spurts corresponding to an incoming high priority D2D voice channel may be received over multiple scheduling periods, for example, until time T2. A device internal request to transmit a low priority D2D data channel (e.g., a second low priority D2D data channel) may be received, for example, starting from time T1. The request may be issued by a user or by an application capable of processing data packets for D2D and capable of issuing such a request. A D2D terminal may have a Tx / Rx front-end that operates under half-duplex constraints for D2D channels and / or signals on the cellular UL frequency, for example, in any subframe in which it may transmit or in which it may receive D2D channels and / or signals. A D2D terminal may be able to receive multiple D2D channels and / or signals (e.g., simultaneously) in the same or similar subframes.

[0284] After the arrival of a transmission request for a low priority D2D data channel (e.g., a second low priority D2D data channel) at time T1, the D2D terminal can adjust its transmission scheduling to enable full reception of one or more or all subframes corresponding to the high priority D2D channel. The D2D terminal can choose not to use some subframes originally scheduled for transmission of the low priority D2D channel and to use the indicated subframes for reception of the high priority D2D data channel, for example, if a collision occurs. At time T2, when the talk spurt of the incoming high priority D2D voice channel ends and a D2D data channel (e.g., only the low priority D2D data channel) can be transmitted, the D2D terminal can adjust its transmission pattern to enable full transmission of the low priority D2D data channel (e.g., a second low priority D2D data channel). While prioritizing reception of high priority D2D channels during time period T1-T2, the D2D terminal may choose to indicate a Radio Resource Transmission Pattern (RRPT) that may be selected as a function of D2D subframes that may be determined to be available for transmission, for example after taking into account those for reception. The D2D terminal may choose to indicate an RRPT that may include D2D subframes for its own transmission and / or in which it may receive high priority D2D data. The D2D terminal may not transmit in these.

[0285] A D2D terminal may process (e.g., automatically process) one or more or multiple D2D channels and / or signals to be transmitted and / or received based on priority processing associated with such multiple D2D channels and / or signals. User intervention such as manual channel switching or deferral of transmission may not be utilized. Signal reception for high priority D2D channels may be received by dedicating reception capability (e.g., full reception capability) to D2D subframes carrying high priority D2D channels and / or signals.

[0286] In some techniques described herein, the SA resources for high priority transmissions by one or more or a given WTRU may be configured to occur earlier in time than the SA resources for low priority transmissions, for example, possibly for the same SA period. This may be configured by the eNB, for example, by assigning them to different SA resource pools. A WTRU with a low priority transmission may decode the high priority SA resources to determine whether higher priority data may be received (e.g., earlier). Possibly, for example, based on this determination, the WTRU may decide not to transmit on the configured low priority SA resources, or the WTRU may transmit on the configured low priority SA resources, among other scenarios. The WTRU may indicate a RRPT while transmitting that may enable it to receive a high priority transmission (e.g., possibly regardless of, for example, a half-duplex configuration in some embodiments).

[0287] The examples described herein may be extended to more than two priority classes. Different lengths of the scheduling period may be used. SA transmissions may correspond to D2D data transmitted in a later scheduling period and / or in multiple scheduling periods. The principle of semi-persistent, time-limited and / or dynamically allowed D2D data transmission may be used, independent of or in conjunction with the scheduling period. Time and / or frequency resources may be non-contiguous. Although the examples used scheduling assignments and / or high and low priority received D2D voice and data channels for illustrative purposes, the principle of allocating transmission and reception subframes corresponding to low or high priority D2D channels or signals may be applied to different D2D channels and / or signal message types as well. For example, D2D discovery messages may be skipped for transmission and / or deferred until later for processing, while high priority D2D control or data signaling may be received. The principle of Rx priority can be applied to the reverse case where D2D subframes may be prioritized for transmission, such as where a high priority D2D channel signal may be transmitted by a D2D terminal while a low priority D2D channel and / or D2D signal may be received.

[0288] The received (e.g., simultaneously received) D2D data can be voice packets, control packets, service packets, and / or data packets, such as IP packets corresponding to a file download. Tx / Rx processing and / or prioritization of multiple channels and / or signals to be received or transmitted may be applied to channels and / or signals received or transmitted over the cellular communication and D2D radio links as well.

[0289] A D2D terminal may determine whether a D2D channel and / or signal (e.g., a second D2D channel and / or signal) may be transmitted or received while receiving or transmitting a D2D channel and / or signal (e.g., a first D2D channel and / or signal). After determining that a D2D channel and / or signal (e.g., a second D2D channel and / or signal) may be present, the D2D terminal may determine which of the D2D channels or signals that may be transmitted or received has a higher priority. The determination may be based on a priority associated with the D2D channel or signal or communication type. The WTRU may determine the priority of the received channel and / or signal based on the priority of the pool or channel on which the data and / or SA is received, time / frequency, etc., which may be based on an explicit indication in the SA, based on a MAC header indication, or based on any of the features described herein.

[0290] A D2D terminal may determine a transmission and / or reception schedule that allows an appropriate number of D2D subframes to be used for transmission or reception of high priority D2D channels and / or D2D signals. The appropriate D2D subframes may be determined based on various criteria such as one or more of a minimum and / or identified set of SA resources on which the D2D terminal may receive or transmit SA, a required number and / or set of D2D subframes corresponding to possible D2D data reception or transmission, a number of sets of subframes that are not available for D2D transmission and / or reception due to ongoing cellular communication, and / or a number and / or set of D2D subframes corresponding to transmission and / or reception from / to one or more WTRUs and / or D2D communication groups.

[0291] The D2D terminal may decide to skip a transmission or reception opportunity initially scheduled for a low priority D2D channel and / or signal. The D2D terminal may select an available transmission / reception opportunity for transmission and / or reception of a lower priority D2D channel and / or signal by determining which transmission / reception opportunity may be used for a high priority D2D channel and / or signal. The WTRU may continue transmitting or receiving a lower priority D2D channel or signal, but may skip transmission or reception in subframes that overlap with subframes in which a higher priority D2D channel or signal is being transmitted or received.

[0292] The D2D terminal may issue notification and / or signaling messages exchanged from, to, or between device components that inform or inform of operations that may be performed as part of its receiver processing in conjunction with the examples described herein. It may issue such notifications or signaling to other devices. The D2D terminal may be configured to perform the examples described herein as a function of, for example, selected reception conditions, receiver configurations, timer or counter values, or index values.

[0293] It is possible for a D2D terminal to process multiple D2D channels and / or signals to be transmitted or received, for example, based on priorities associated with those D2D channels or signals. The processing may include selection of transmission and / or reception opportunities for a D2D channel and / or signal (e.g., a first D2D channel and / or signal) as a function of what is useful for the D2D channel and / or signal (e.g., a second D2D channel and / or signal).

[0294] Reception processing of multiple D2D data channels by a device may be described herein.

[0295] It is possible for a D2D terminal to process multiple received (eg, simultaneously received) D2D channels or signals based on the priority of the received D2D channels and / or signals.

[0296] A receiving D2D terminal may receive multiple incoming (e.g., simultaneously arriving) D2D channels or signals. Based on the priority for the received D2D channels or signals, it may store (e.g., temporarily store) in memory the received channel samples, demodulated or decodable bitstreams or decoded information content that may correspond to the received lower priority D2D channels and / or signals, while processing and / or forwarding and / or presenting to a user or device output another higher priority D2D channel and / or signal.

[0297] 10 is an example diagram of multiple simultaneously received D2D channels (e.g., voice), in which a D2D terminal can simultaneously receive a D2D voice channel (e.g., a first high priority D2D voice channel) such as for an emergency first responder direct voice line and / or a D2D voice channel (e.g., a second lower priority D2D voice channel) such as for a push-to-talk group call.

[0298] In FIG. 10, talk spurts corresponding to a high priority D2D voice channel (e.g., a first high priority D2D voice channel) may be received over multiple scheduling periods until time T2. Talk spurts of a low priority D2D voice channel (e.g., a second low priority D2D voice channel) may be received starting at time T1. A D2D terminal may have one audio processing front-end chain, e.g., at any given time, decoded (e.g., only decoded) voice samples of one channel may be presented to an audio output such as a speaker or otherwise, and the D2D terminal may process (e.g., only process) one received voice channel at a time. A D2D terminal may be able to simultaneously receive both low priority and / or high priority D2D channels and / or control signaling in different subframes or in the same or similar subframes that may be used to carry the D2D channels and / or D2D signals.

[0299] Possibly, in among other scenarios, after initiation of reception of a low priority D2D voice call (e.g., the second low priority D2D voice call in FIG. 10) at time T1, the D2D terminal may continue to demodulate, decode, and / or forward to the device's audio output path any D2D data acquired from a high priority voice channel (e.g., the first high priority voice channel in FIG. 10), while it may store (e.g., temporarily store) in memory decoded samples or signal representations of a (e.g., simultaneously) received lower priority D2D voice call (e.g., the second lower priority D2D voice call in FIG. 10). At time T2, if the talk spurt of the high priority D2D voice channel (e.g., the first high priority voice channel in FIG. 10) ends and a low priority D2D voice channel (e.g., only the low priority D2D voice channel in FIG. 10) can be received, the D2D terminal can switch its audio path from the high priority D2D voice channel to the low priority D2D voice channel. Transferring such stored channel samples and / or decoded information content corresponding to the low priority D2D voice channel from memory (e.g., temporary memory) to the audio path can include a time delay or lag. For example, in FIG. 10, three scheduling periods, or about 480 ms, or 24 voice frames in each 20 ms codec interval, are processed and played out from the temporary memory. One or more (e.g., many) D2D applications can support push-to-talk type voice rather than two-way conversation voice. Such a time delay or lag introduced through storing (e.g., temporarily storing) the low priority D2D voice channel can be acceptable.

[0300] D2D receiver processing may be enhanced, for example, in that a D2D terminal may receive and / or process multiple D2D channels or signals (e.g., simultaneous D2D channels or signals) based on (e.g., automatically) priority processing associated with such received multiple D2D channels and / or signals. Any user intervention similar to manual channel switching may not be useful. Higher priority D2D channels and / or signals may be prioritized via D2D terminal processing after reception, for example, in the presence of other channels and / or signals.

[0301] The WTRU may be configured or pre-configured with rules to determine whether data of different priorities may be multiplexed together in a PDU or whether they may be required to be transmitted in different transmission opportunities. For example, the network may allow the WTRU to multiplex data belonging to a second priority level and a third priority level, but not data corresponding to a first priority level. This constraint may be beneficial, for example, if the WTRU wants to optimize the transmission of emergency services without multiplexing lower priority data into the same TB.

[0302] The examples described herein and FIG. 10 may be extended to more than two priority classifications. Different lengths of the scheduling period may be used. SA transmissions may correspond to D2D data transmitted in a later scheduling period and / or in multiple scheduling periods. The principles of semi-persistent, time-limited, and / or dynamically allowed D2D data transmissions may be used, independent of or in conjunction with the scheduling period. Time and / or frequency resources may be non-contiguous. Although the examples used scheduling assignments and high and low priority received D2D voice channels for illustrative purposes, the principles of temporarily buffering and storing samples corresponding to low priority D2D channels and / or D2D signals may be applied to different D2D channels and / or signal message types as well. For example, D2D discovery messages may be stored (e.g., temporarily) for processing at a later time, while high priority D2D control or data signaling may be processed after reception.

[0303] The received D2D data (e.g., simultaneously received D2D data) can be voice packets, control packets, service packets, and / or data packets, such as, for example, IP packets corresponding to a file download. The use of buffering and / or storing in memory (e.g., temporarily buffering and / or storing) samplings corresponding to a received D2D channel (e.g., a second received D2D channel) may be applied to avoid receiver limitations in the D2D terminal with respect to, for example, device architecture, component availability for real-time processing, device output representation of the received D2D data, and / or required user interaction, etc. Receiver processing and / or prioritization of multiple received (e.g., simultaneously received) channels and signals may be similarly applied to channels or signals received from cellular communication and D2D radio links.

[0304] While receiving a D2D channel and / or signal (e.g., a first D2D channel and / or signal), the D2D terminal may determine whether a D2D channel and / or signal (e.g., a second D2D channel and / or signal) may be received. After determining that a D2D channel and / or signal (e.g., a second D2D channel and / or signal) may be received, the D2D terminal may determine which one of the received (e.g., simultaneously received) D2D channels or signals may be directly processed and / or which one may be stored (e.g., temporarily stored) in memory. The determination may be based on a priority associated with the received D2D channel or signal or communication type. Direct processing of any decoded samples of the D2D channels and / or signals may imply presenting these samples to a user output, such as the terminal's audio path, or it may imply forwarding such samples as application processing data packets to other processing components running on the D2D terminal. Storing (or temporary storing) in memory may be combined with partial receiver processing, such as for channel demodulation of the received D2D channels and / or signals, or for channel decoding techniques of the demodulated samples, or for protocol processing of such samples. The D2D terminal may decide when to process any D2D data stored (e.g., temporarily stored) in memory. The D2D terminal may decide to apply direct processing to the stored (e.g., temporarily stored) samples or information content of the D2D channels and / or signals, for example, as described herein. The D2D terminal may forward the stored samples to an output component of the device, such as audio or video or other processing logic or application that processes the data received on the device.It may be possible, for example, to determine that a stored sample may be discarded if a time delay or a selected set of conditions is met. The sample may be stored in permanent storage, for example, to allow an end user to listen at a later point in time.

[0305] The D2D terminal may issue notification and / or signaling messages exchanged from, to, or between device components that inform or inform about operations that may be performed as part of its receiver processing in conjunction with the examples described herein. It may issue such notification or signaling messages to other devices. The D2D terminal may be configured to perform the examples described herein as a function of selected reception conditions, receiver configurations, timer or counter or index values.

[0306] A D2D terminal may process multiple received D2D channels or signals, for example, based on the priority of the received (e.g., simultaneously received) D2D channels or signals. Processing may include, for example, receiving and / or discarding and / or prioritizing for reception D2D channels and / or signals in the presence of other D2D channels or signals.

[0307] A D2D terminal may, for example, select a received (e.g., a first received) D2D channel and / or signal for direct processing while selecting a received (e.g., a second received) D2D channel and / or signal for storage (e.g., temporary storage). The direct processing and / or temporary storage may, for example, correspond to the example implementations described herein with respect to the example receiver.

[0308] One or more techniques are contemplated for reception by a D2D WTRU acting as a relay node. A relay WTRU may operate as an L3 relay. In such a scenario, data received on the D2D link, among other things, may possibly be forwarded to one or more higher layers (e.g., IP, among other things) before it can be transmitted to the eNB over the Uu interface, for example. A relay WTRU may possibly perform (e.g., specific) processing on priority, for example, when it is capable of receiving data (e.g., on the D2D link) and / or relaying this traffic to the network over the cellular link. The priority of data transmitted by the WTRU to the network (e.g., via a relay) may be the same, or substantially similar, priority on the D2D link as the priority experienced over the cellular link from the relay WTRU to the eNB.

[0309] In one or more techniques, a relay node may, for example, request and / or create one or more separate radio bearers for one or more, or each level of priority of data it may receive from any of the remote WTRUs it may currently be serving. The relay WTRU may utilize one or more existing radio bearers, which may be associated with (e.g., various) degrees of quality of service (QoS), to possibly service one or more different priority transmissions made by the remote WTRU, for example, towards a relay (e.g., with higher priority transmissions mapped to one or more bearers with better QoS, or the like), among other scenarios.

[0310] The relay WTRU may set up one or more, or a set of radio bearers for one or more, or each, of the N priority levels that it may be serving, and / or the WTRU may select one or more existing radio bearers that may be used for data associated with one or more, or each priority level. Possibly, for example, in the case where the relay WTRU receives data from a D2D link, among other scenarios, it may determine the priority of packets received from the remote WTRU. This determination may be made, for example, at the MAC layer, the IP layer, and / or the application layer, among other layers. For example, if the determination is made at the MAC layer, the priority level of the received MAC PDU may be determined by one or more of the following: having a transmitter of a MAC PDU include a priority level in the MAC header, in which, inter alia, in such a scenario, the receiving MAC entity can determine the priority based on the associated priority level found in the MAC header for that PDU; and / or Assume a static and / or determined mapping between logical channel IDs and priorities. Logical channel ID values ​​can be associated with specific priorities. For example, LCIDs 1-8 can be utilized for D2D communications, and priority levels can be associated with selected IDs (e.g., in order of increasing / decreasing priority).

[0311] The WTRU may transmit the received data, possibly along with an associated priority level, to one or more higher layers (e.g., the IP layer) for forwarding over the cellular link.

[0312] For example, if the priority determination is made at the IP layer and / or the application layer, an associated priority may be transmitted along with the IP packet and / or along with the associated application layer data, such that, for example, a relaying WTRU may be aware of the priority of the received data. The data may be forwarded (e.g., onward) to one or more higher layers where the priority determination may be performed.

[0313] Possibly, for example, based on the priority of the received data, the relay WTRU may determine which radio bearer (e.g., having an associated QoS level) to use for transmission of the received data. The relay WTRU may maintain a mapping of radio bearers to priority levels and / or use this mapping to determine on which radio bearer one or more IP packets may be transmitted. The WTRU may be configured (e.g., dynamically) with a mapping of priority levels to radio bearers by the eNB and / or may use this mapping to transmit one or more IP packets on one or more existing radio bearers.

[0314] In some techniques, one or more, or multiple radio bearers having the same or similar QoS characteristics may be used to transmit data received by the relay WTRU from the remote WTRU to the eNB / network. The relay WTRU may (e.g., selectively) forward higher priority data to one or more higher layers, possibly, for example, while buffering the lower priority data for a period of time. The relay WTRU may process the higher priority (e.g., forwarded to a higher layer) if it is processing one or more, or each, of the logical channels that may be used to transmit data received from the remote WTRU, among other scenarios, and / or may process the lower priority data if (e.g., only if) the lower priority data is forwarded to a higher layer.

[0315] For example, the relay WTRU may possibly be configured with a timer during which, e.g., lower priority data may be buffered while forwarding higher priority data. The timer may be reset one or more times, or each time a higher priority packet is received by the relay WTRU and / or forwarded to one or more higher layers. The WTRU may possibly forward the buffered lower priority data to one or more higher layers after (e.g., only after) the timer expires (e.g., may indicate that no higher priority data has been received for a period of time), among other scenarios.

[0316] For example, the relay WTRU may forward lower priority data over a scheduling period, possibly if, e.g., only if, no higher priority data has been received over that scheduling period. Possibly, for example, if a given scheduling period at the WTRU experiences reception of high priority data, one or more, or all, of the lower priority data may be buffered in one or more lower layers at the relay WTRU while the higher priority data (e.g., only the higher priority data) may be forwarded to one or more higher layers.

[0317] In some techniques, the WTRU may forward data to higher layers (e.g., selectively) with a certain probability. A higher probability of forwarding may be associated with higher priority data / channels and / or a lower probability of forwarding may be associated with lower priority data / channels. The higher layers may possibly process data in the order in which it was received, for example.

[0318] For example, a relay WTRU receiving data having, for example, two different priorities (e.g., high and low) may be configured with a first probability (P1)=0.8 for the higher priority data and / or a second probability (P2)=0.2 for the lower priority data. Possibly, for example, if the relay WTRU contains high priority data and / or low priority data that is to be forwarded to one or more higher layers at any one time, the relay WTRU may select a random number between 0 and 1. For example, the relay WTRU may possibly forward the high priority data if the number is greater than 0.2. Possibly, for example, the relay WTRU may forward the lower priority data if the number is otherwise.

[0319] Although some techniques may be described herein using two priority levels, any of the contemplated techniques may be extended to multiple (N) priorities by one of ordinary skill in the art.

[0320] Transmissions that process multiple D2D data channels at a device may be described herein. It is possible for a D2D terminal to process multiple D2D channels or signals (e.g., simultaneous D2D channels or signals) to be transmitted based on the priority of the D2D channels or signals.

[0321] A D2D terminal may transmit and / or desire to transmit multiple D2D channels or signals (e.g., simultaneously) and based on the priorities for the D2D channels or signals to be transmitted, it may store (e.g., temporarily store in memory) information content or encoded bitstreams or samples corresponding to a lower priority D2D channel and / or signal to be transmitted, while, for example, processing and / or forwarding and presenting to the transmission path another higher priority D2D channel and / or signal.

[0322] A D2D terminal may transmit and / or desire to transmit a D2D signal when resources may not be available for transmission. It may, for example, store (e.g., temporarily store) the information content or encoded bitstream or samples of this signal until resources may be available and / or until a timer expires. After expiration of the timer, the samples may be discarded or stored in storage (e.g., permanent storage) to allow an end user to later access the untransmitted signal.

[0323] 11 is an example diagram of multiple simultaneous D2D channels (e.g., voice and data) to be transmitted, in which a D2D terminal may transmit (e.g., simultaneously transmit) a higher priority D2D voice channel (e.g., a first high priority D2D voice channel) and / or a lower priority D2D channel (e.g., a second lower priority D2D channel), such as a voice call group channel.

[0324] In FIG. 11, a talk spurt corresponding to a high priority D2D voice channel (e.g., a first high priority D2D voice channel) may be processed by a D2D terminal over multiple scheduling periods, for example, until time T2. A device internal request to transmit a low priority D2D data channel (e.g., a second low priority D2D data channel) may be received, for example, starting from time T1. The request may be issued by a user or by an application capable of processing data packets for D2D and / or issuing such a request. The D2D terminal may have a transmission (e.g., single transmission) front-end chain. In any given subframe, one or more (e.g., only one) transport blocks (TB) of the D2D channel may be presented to the Tx path, for example, to use its (e.g., complete) available output power on that subframe for the considered D2D channel. This may maximize the feasible link budget for the D2D channel. A D2D terminal may be able to transmit high priority and / or low priority D2D channels and / or their control signaling (eg, simultaneously) in different subframes.

[0325] After the arrival of a transmission request for a low priority D2D data channel (e.g., a second low priority D2D data channel) at time T1, the D2D terminal may continue to forward any D2D data that may be available for the high priority voice channel (e.g., a first high priority voice channel) to the transmission path, while it stores (e.g., temporarily stores) and / or buffers in memory any samples or signal representations of a lower priority D2D data channel (e.g., a second lower priority D2D data channel) to be transmitted (e.g., to be transmitted simultaneously). At time T2, when the talk spurt of the high priority D2D voice channel (e.g., a first high priority D2D voice channel) ends and a low priority D2D data channel (e.g., only the low priority D2D data channel) may be transmitted, the D2D terminal may switch its transmission path from the high priority D2D voice channel to the low priority D2D data channel. Transferring such stored samples and / or information content corresponding to low priority D2D data channels from memory (e.g., temporary memory) to a transmit path may include a time delay or lag. For example, in FIG. 11, about three scheduling periods, or about 480 milliseconds, may be processed from the temporary memory. If the D2D application may correspond to a data type that is not time critical, e.g., other than two-way conversational voice, the time delay or lag introduced through storing (e.g., temporarily storing) part or the entire low priority D2D data transmission may be acceptable.

[0326] In Fig. 11, the D2D terminal may, for example, intermittently multiplex lower priority D2D data transmissions during an ongoing higher priority D2D voice channel transmission. It may do so in D2D subframes (e.g., only in D2D subframes in Fig. 11) that may not be used for transmission of transport blocks for the higher priority D2D voice channel. Lower priority D2D data may have been transmitted between T1 and T2 that is ready for transmission by time T2 and may be received by the transmission path between time T1 and T2 for the low priority channel.

[0327] D2D transmitter processing may be enhanced in that the D2D terminal may process (e.g., automatically process) multiple D2D channels or signals to be transmitted (e.g., simultaneous D2D channels or signals) based on priority processing associated with such multiple D2D channels and / or signals to be transmitted. Any user intervention, such as manual channel switching or postponement of transmission, may not be useful. Higher priority D2D channels and / or signals may be prioritized via D2D terminal processing, for example, after a request to transmit in the presence of other channels or signals.

[0328] The example described herein and shown in FIG. 11 may be extended to the case of more than two priority classes. Different lengths of the scheduling period may be used. SA transmissions may correspond to D2D data transmitted in a later scheduling period or in multiple scheduling periods. Independently of or in conjunction with the scheduling period, the principle of semi-persistent, time-limited, and / or dynamically allowed D2D data transmission may be used. Time and / or frequency resources may be non-contiguous. The example may be using scheduling assignments for illustrative purposes, as well as high and low priority received D2D voice and data channels to be transmitted. The principle of temporarily buffering and storing samples corresponding to low priority D2D channels and / or D2D signals to be transmitted may be applied to different D2D channels and / or signal message types as well. For example, high priority D2D control or data signaling may be processed after receipt of a request to transmit at the D2D terminal, while a D2D discovery message to be transmitted may be stored (e.g., temporarily stored) and / or queued for processing at a later time.

[0329] The D2D data channels or signals (e.g., simultaneous D2D data channels or signals) to be transmitted can be voice packets, control packets, service packets, and / or data packets, such as, for example, IP packets corresponding to a file upload. The use of buffering and / or storing in memory (e.g., temporary buffering and / or storing) samples corresponding to a D2D channel (e.g., a second D2D channel) to be transmitted can be applied to avoid transmitter limitations in the D2D terminal with respect to device architecture, component availability for real-time processing, device output representation of D2D data, radio resource usage, and / or required user interaction, etc. Transmitter processing and / or prioritization of multiple channels and / or signals (e.g., simultaneous channels and / or signals) to be transmitted can be applied to channels or signals to be transmitted over cellular communication and D2D radio links as well.

[0330] The D2D terminal may determine whether a request to transmit a D2D channel and / or D2D signal (e.g., a second) may be received while transmitting a D2D channel and / or D2D signal (e.g., a first D2D channel and / or D2D signal). After determining that a D2D channel and / or D2D signal (e.g., a second D2D channel and / or D2D signal) will be transmitted, the D2D terminal may determine which of the D2D channels or D2D signals (e.g., simultaneous D2D channels or D2D signals) to be transmitted may be processed directly and which may be stored (e.g., temporarily stored) in memory. The determination may be based on a priority associated with the D2D channel or D2D signal or communication to be transmitted. Directly processing samples or information representing the D2D channel and / or D2D signal to be transmitted may imply presenting the information to the transmission path of the terminal or it may imply forwarding such samples to other processing components running on the D2D terminal. Storing in memory (e.g., temporarily storing) may be combined with partial transmitter processing, such as channel modulation of the D2D channel and / or D2D signal to be transmitted, channel coding of the information, and / or protocol processing of such D2D channel or D2D signal.

[0331] The D2D terminal may determine when to process the (temporarily stored) D2D data stored in memory. The D2D terminal may determine to apply direct processing to such stored (e.g., temporarily stored) samples or information content of the D2D channel and / or D2D signal to be transmitted, for example, as described herein. The D2D terminal may forward the stored samples to an output component of the device, such as a transmitter path. It may determine that the stored samples may be discarded, for example, if a selected set of time delays and / or conditions may be met. The device may, for example, as part of a transmitted (e.g., simultaneously transmitted) portion of a low priority D2D channel and / or D2D signal (e.g., a second low priority D2D channel and / or D2D signal), during a time period in which it may transmit a higher priority D2D channel, such as in a subframe that may not be in use by a higher priority D2D channel and / or D2D signal.

[0332] The D2D terminal may issue notification and / or signaling messages exchanged from, to, or between device components that inform and / or inform of operations that may be performed as part of its transmitter processing in conjunction with the examples described herein. It may issue such notification or signaling messages to other devices. The D2D terminal may be configured to perform the examples described herein as a function of, for example, selected conditions, transmitter configurations, timer or counter values, or index values.

[0333] It is possible for a D2D terminal to process multiple D2D channels or signals to be transmitted based on the priority of the simultaneous D2D channels or signals to be transmitted, which may include, for example, transmitting and / or discarding and / or prioritizing portions or the entire D2D channels and / or signals to be transmitted in the presence of other D2D channels or signals to be transmitted by the device.

[0334] A D2D terminal may select a D2D channel and / or a D2D signal (e.g., a first D2D channel and / or a D2D signal) to be transmitted for direct processing while selecting a D2D channel and / or a D2D signal (e.g., a second D2D channel and / or a D2D signal) to be transmitted for storage (e.g., temporary storage). The direct processing and / or storage (e.g., temporary storage) may correspond to example implementations described herein with respect to the transmitter.

[0335] A D2D terminal may transmit D2D data by determining a priority access group and / or mapping to available priorities or priority access groups from available D2D data channels or D2D signals.

[0336] A priority access group may be selected to transmit the data.

[0337] The WTRU may be configured with several separate priority access groups and may have multiple services or applications running. The WTRU may decide how to map the D2D data to be transmitted to the available priority access groups.

[0338] A priority access group may refer to any of the schemes or resource pool configurations described herein that support data priority and / or traffic differentiation (e.g., different resource pools with different priorities, priority access within the same resource pool, etc.).

[0339] The WTRU may determine the priority access group to use based on one or more or a combination of the following parameters described herein: The WTRU may use a configured mapping between logical channel priorities or LCG priorities of ProSe bearers, and / or ProSe / application layer packets, and / or priority access groups. For example, a ProSe bearer configured with logical channel priorities 1-4 may be mapped to priority access group 1 or the highest priority group. One or more or each service associated with a particular group, traffic type, and / or user type may have an assigned priority by a higher layer. When a packet arrives at the access stratum, it may be mapped to a logical channel or PDCP entity based on the group destination, source destination, and / or associated priority. For a given logical channel, the WTRU may know the priority of the packet, and based on the mapping, the WTRU may determine which priority access group the packet or logical channel belongs to. The WTRU may determine the priority access group based on the mapping of TFTs to priority access groups or to logical channel (or packet) priorities. A WTRU may be configured with one or more, or a set of TFT filters for each traffic type, and one or more, or a priority of logical channels or access groups to be associated with each traffic type. For example, a WTRU may be configured with (e.g., three) TFT filters and one or more of them, or a mapping rule for each (e.g., voice traffic is mapped to priority access group 1, video traffic is mapped to priority access group 2, and data traffic is mapped to priority access group 3).The WTRU may perform traffic inspection to determine the traffic class of one or more, or each, packet, and / or it may look up configured mapping rules to determine, for example, which priority access group may be used.

[0340] The WTRU may possibly determine the priority access group to use based on a mapping of EPS bearers and / or radio bearers on which a WTRU acting as a repeater and / or receiving data (e.g., earlier) on the cellular / Uu link may receive data to priority access groups on the D2D link. For example, a WTRU acting as a repeater may be configured with separate EPS / radio bearers transmitting data for different priority levels. The WTRU may map data received on a particular EPS bearer to a particular priority access group, possibly based on a mapping that is predefined and / or signaled (e.g., by the eNB or ProSe function).

[0341] For each device, the WTRU may determine the priority access group based on the device configuration (e.g., one or more or all services from that device may use the same or similar priority access, or may always use). The WTRU may be configured with device / WTRU priorities, for example, based on a hierarchy in the group (e.g., the Fire Chief is configured to have the highest priority in the group). The WTRU may determine the priority access group based on observed traffic characteristics at the WTRU. The WTRU may keep historical and / or ongoing traffic characteristics (e.g., inter-arrival time, data rate, etc.) and / or determine an appropriate priority access group that may be used to meet those traffic characteristics. The WTRU may determine the priority access group based on a function of the D2D WTRU. For example, if the WTRU may be operating as a repeater, some or all traffic may be mapped to a priority access group, or the WTRU may be configured to use a different (higher) priority access group when operating as a repeater. The WTRU may determine the priority access group as a function of the services configured by the higher layer. For example, if a higher layer requested a D2D request for emergency services, the WTRU may determine the utility of using the emergency priority access group.

[0342] The configuration parameters described herein may be provided to the WTRU along with the D2D service or bearer configuration, such as by RRC or higher layer signaling (e.g., from a ProSe function). The WTRU may be pre-configured with the mapping rules.

[0343] An in-coverage WTRU may be configured to report the priority access groups that the WTRU may be using to the ProSe function / eNB. The eNB may be provided with the configuration parameters described herein (e.g., mapping of LCG IDs, logical channels, priority levels, and / or priority access groups) from the ProSe function and / or from another node in the network (e.g., MME), for example, among other scenarios in which the mapping may not be determined (e.g., solely) by the WTRU.

[0344] The selected priority access pool may be utilized for the transmission.

[0345] The WTRU may determine how to multiplex data into a selected priority access group and / or to transmit data using characteristics of the priority access group. Features described herein may be applicable to cases where the WTRU may multiplex data belonging to one source-destination pair (e.g., only such data) in one transport block and / or may be applicable to cases where the WTRU may multiplex data belonging to different destinations.

[0346] The WTRU can decide how to multiplex and where to transmit some or all data using one or more (e.g., only one) determined priority access groups. For example, the WTRU can decide to transmit all D2D using the priority access group with the highest priority among the selected access groups (e.g., if a D2D emergency service is requested by a higher layer, some or all traffic from the device may be transmitted using the emergency priority access group). For example, the WTRU can determine the highest priority service or priority access group for which data is available and determine the resources or transmission characteristics on which this priority service may be transmitted. The WTRU may be enabled to multiplex the priority services together (e.g., any of the priority services together) and transmit them using the transmission characteristics of the highest priority data. Logical channel prioritization may be performed at the transmitter, for example, to prioritize higher traffic classes from lower traffic classes for one or more or each PDU creation. In cases where the WTRU is limited to multiplexing data from one source-destination pair, the WTRU can determine the highest priority service or data across destinations (e.g., all destinations), determine the transmission characteristics and resources for that priority, and can multiplex data from different priorities belonging to that destination in the same PDU, e.g., depending on the LCP and available space.

[0347] The logical channels that may be multiplexed together may be further restricted to the destination to which the highest priority service in that access group belongs.

[0348] Data may be segregated to be transmitted using multiple priority access groups. For example, the WTRU may decide to multiplex data belonging to the same priority access group together and / or transmit them using the characteristics of the selected priority access group. If one or more (e.g., two) priority access groups are configured (e.g., high and low), the WTRU may categorize the configured logical channels into one or more (e.g., two) groups, and it may perform (e.g., separate) logical channel prioritization to multiplex one or more, or logical channels within each group into separate packets.

[0349] One or more, or each packet may be transmitted to a lower layer, e.g., along with a priority access group indicator. One or more, or each packet may be associated with a separate indicator, e.g., to indicate that preemption may be used (e.g., if supported) to transmit that packet.

[0350] Triggers for determining a priority access group may be described herein. The WTRU determines the usefulness of selecting a priority access group and / or changes the priority access group it may be using upon detecting one or more of the following triggers: after start / end of a D2D service (e.g., emergency call), when D2D data may be available for transmission, when D2D data may be available for transmission, e.g., at the beginning of a scheduling period, when the WTRU's capabilities have changed (e.g., the WTRU may start and / or stop operating as a repeater), when a new D2D resource configuration may be provided from a higher layer.

[0351] The priority access group may change. If the WTRU is able to select a new priority access group and / or decide to remap D2D data to a different priority access group, the WTRU may be configured to perform one or more of the following actions: stop using an earlier priority access group for resource selection, determine traffic types and logical channels or groups of logical channels that may belong to the selected priority access group, perform resource selection to select resources and / or transmission opportunities for one or more of the selected priority access groups, or each, perform logical channel priority for one or more or all logical channels that may belong to the selected priority access group, and / or generate a packet.

[0352] Although the features and elements are described with reference to LTE (e.g., LTE-A) and LTE terminology, the features and elements described herein may have application to other wired and wireless communication protocols, such as HSPA, HSPA+, WCDMA, CDMA2000, GSM, WLAN, and / or the like.

[0353] Although the features and elements are described above in certain combinations, one skilled in the art will recognize that one or more, or each feature or element may be used alone or in any combination with the other features and elements. Additionally, the methods described herein may be implemented in a computer program, software, or firmware embodied in a computer-readable medium for execution by a computer or processor. Examples of computer-readable media include electronic signals (transmitted over wired or wireless connections) 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 memory devices, magnetic media such as internal hard disks 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 execute a radio frequency transceiver for use in a WTRU, a WTRU, a terminal, a base station, an RNC, or any host computer.

Claims

1. A first wireless transmit / receive unit (WTRU), receiving a first scheduling assignment for a first sidelink data transmission from a second WTRU, the first scheduling assignment including an indication of one or more first resources and an indication of a first priority; determining to send a second sidelink data transmission, the second sidelink data transmission being associated with a second priority, the second priority being lower than the first priority; determining a signal strength associated with the first scheduling assignment; selecting one or more resources for sending the second sidelink data transmission, the first WTRU determining that the one or more resources are available for sending the second sidelink data transmission based at least on a signal strength associated with the first scheduling assignment being less than a threshold; sending a second scheduling assignment for the second sidelink data transmission, the second scheduling assignment including an indication of the selected one or more resources. A first WTRU comprising a processor configured to:

2. The processor, The first WTRU of claim 1 , further configured to determine that the signal strength associated with the first scheduling assignment is less than the threshold.

3. 3. The first WTRU of claim 2, wherein at least one of the one or more resources is selected for sending the second sidelink data transmission based at least on the signal strength associated with the first scheduling assignment being less than the threshold.

4. The processor, The first WTRU of claim 1 , further configured to determine that the signal strength associated with the first scheduling assignment is greater than the threshold.

5. 5. The first WTRU of claim 4, wherein the one or more resources are excluded from resource selection for the second sidelink data transmission based at least on the signal strength associated with the first scheduling assignment being greater than the threshold.

6. 2. The first WTRU of claim 1, wherein the signal strength associated with the first scheduling assignment corresponds to a signal strength of the one or more first resources indicated for the first sidelink data transmission.

7. The first WTRU of claim 1 , wherein the signal strength associated with the first scheduling assignment corresponds to a signal strength of a resource used to receive the first scheduling assignment.

8. The first WTRU of claim 1 , wherein the processor is configured to receive a resource release indication corresponding to the one or more first resources.

9. The first WTRU of claim 8 , wherein the one or more first resources are considered available for sending a transmission of the second priority data based at least on receiving the resource release indication.

10. The first WTRU of claim 1 , wherein the threshold value is included in a configuration received by the first WTRU.

11. 1. A method implemented by a first wireless transmit / receive unit (WTRU), comprising: receiving a first scheduling assignment for a first sidelink data transmission from a second WTRU, the first scheduling assignment including an indication of one or more first resources and an indication of a first priority; determining to send a second sidelink data transmission, the second sidelink data transmission being associated with a second priority, the second priority being lower than the first priority; and determining a signal strength associated with the first scheduling assignment; selecting one or more resources for sending the second sidelink data transmission, wherein the first WTRU determines that the one or more resources are available for sending the second sidelink data transmission based at least on a signal strength associated with the first scheduling assignment being less than a threshold; and sending a second scheduling assignment for the second sidelink data transmission, the second scheduling assignment including an indication of the selected one or more resources; and A method comprising:

12. The method of claim 11 , further comprising determining that the signal strength associated with the first scheduling assignment is less than the threshold.

13. 13. The method of claim 12, wherein at least one of the one or more resources is selected for sending the second sidelink data transmission based at least on the signal strength associated with the first scheduling assignment being less than the threshold.

14. The method of claim 11 , further comprising determining that the signal strength associated with the first scheduling assignment is greater than the threshold.

15. 15. The method of claim 14, wherein the one or more resources are excluded from resource selection for the second sidelink data transmission based on the signal strength associated with the first scheduling assignment being greater than the threshold.

16. 12. The method of claim 11 , wherein the signal strength associated with the first scheduling assignment corresponds to a signal strength of the one or more first resources indicated for the first sidelink data transmission.

17. The method of claim 11 , wherein the signal strength associated with the first scheduling assignment corresponds to a signal strength of a resource used to receive the first scheduling assignment.

18. The method of claim 11 , further comprising receiving a resource release indication corresponding to the one or more first resources.

19. 20. The method of claim 18, wherein the one or more first resources are considered available for sending a transmission of the second priority data based at least on receiving the resource release indication.

20. The method of claim 11 , wherein the threshold value is included in a configuration received by the first WTRU.