Device-to-device (D2D) preemption and access control

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

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 on August 6, 2014, U.S. Provisional Patent Application No. 62 / 144,132, filed on April 7, 2015, and U.S. Provisional Patent Application No. 62 / 161,108, filed on May 13, 2015, and the entire disclosures of all of the above applications are hereby incorporated by reference as if fully set forth herein.

Background Art

[0002] Device - to - device (D2D) communication can be utilized for various purposes such as public safety communication. D2D communication can be associated with standardized technologies such as LTE, IEEE, etc. In an LTE system, access control and / or priority handling can be used to mediate access and / or use of radio resources by a terminal.

Summary of the Invention

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

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

[0005] Embodiments may, for example, be intended for priority reception and / or priority transmission related to D2D relay. Embodiments may also be intended for signaling related to the use of (e.g., guaranteed) segregated resources.

[0006] A wireless transceiver unit (WTRU) may include a receiver. The receiver may be configured to receive allocations of one or more radio resources relating to one or more scheduling allocations (SAs). The WTRU may include 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 allocated to at least one of a first priority device-to-device (D2D) transmittance. The processor may be configured to determine a second FD SA pool. The second FD SA pool may include one or more SAs allocated to at least one of a second priority D2D transmittance. The WTRU may include a transmitter. The transmitter may be configured to transmit at least one first priority D2D transmittance using at least one radio resource relating to one or more SAs from the first FD SA pool. The transmitter may be configured to transmit at least one second priority D2D transmittance using at least one radio resource relating to one or more SAs from the second FD SA pool.

[0007] A wireless transceiver unit (WTRU) can perform device-to-device (D2D) communication. The WTRU may include 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 include a processor. The processor may be configured to determine whether at least one of a second D2D channel or a second D2D signal will be transmitted while at least one of the first D2D channel or a first D2D signal is being received. If the processor determines that at least one of the second D2D channel or a second D2D signal will be transmitted while at least one of the first D2D channel or a first D2D signal is being received, it may be configured to determine a relative priority between at least one of the first D2D channel or a first D2D signal and at least one of the second D2D channel or a second D2D signal. The processor may be configured to determine the number of D2D subframes that will be used to receive which of the first D2D channel or first D2D signal, or the second D2D channel or second D2D signal, has a higher relative priority.

[0008] A wireless transceiver unit (WTRU) can perform device-to-device (D2D) communication. The WTRU may include a processor. The processor may be configured to decide whether to transmit a preemption indicator. The processor may be configured to decide whether to transmit a preemption indicator via a scheduling assignment (SA). The WTRU may also include 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 transceiver unit (WTRU) may include a receiver. The receiver may be configured to receive allocations of one or more radio resources relating to one or more scheduling assignments (SAs). The WTRU may include a processor. The processor may be configured to determine a first SA pool. The first SA pool may include one or more SAs allocated to at least one of a first priority device-to-device (D2D) transmission. The processor may be configured to determine a second SA pool. The second SA pool may include one or more SAs allocated to at least one of a second priority D2D transmission. The processor may be configured to compare the number of first priority scheduling occurrences associated with one or more resources relating to one or more SAs in the first SA pool with a threshold. The WTRU may include a transmitter. The transmitter may be configured to transmit at least one first priority D2D transmission using at least one radio resource relating to one or more SAs from the first SA pool when its number is equal to or exceeds a threshold. [Brief explanation of the drawing]

[0010] A more detailed understanding can be gained from the following explanation, which is provided as an example in conjunction with the attached drawings. [Figure 1A] This is a system diagram showing an exemplary communication system in which one or more disclosed embodiments may be implemented. [Figure 1B] Figure 1A is a system diagram showing an exemplary wireless transceiver unit (WTRU) that may be used in the communication system shown. [Figure 1C] Figure 1A is a system diagram showing exemplary radio access networks and exemplary core networks that may be used within the communication system shown. [Figure 1D] Figure 1A is a system diagram showing another exemplary radio access network and an exemplary core network that may be used within the communication system shown. [Figure 1E] Figure 1A is a system diagram showing another exemplary radio access network and an exemplary core network that may be used within the communication system shown. [Figure 2] This figure shows an example of priority-based access via TDM in SA and D2D data subframes. [Figure 3] This figure shows an example of priority-based access for D2D communication via SA's TDM in shared D2D data subframes. [Figure 4] This figure shows an example of priority-based access for D2D communication via FDM in SA and D2D data subframes. [Figure 5] This figure shows an example of priority-based access for D2D communication via SA's FDM in shared D2D data subframes. [Figure 6] This figure shows an example of priority-based access via different resource allocation densities (e.g., TDM) for D2D subframe pools. [Figure 7] This figure illustrates an example of priority-based access through different resource allocation densities (e.g., transmission patterns). [Figure 8] This figure illustrates an example of priority-based access to D2D data using persistence parameters (e.g., SA). [Figure 9] This figure shows an example of prioritized reception of a high-priority channel by a D2D terminal with FDD half-duplex operation. [Figure 10] This diagram illustrates an example of multiple D2D channels (e.g., audio) being received simultaneously. [Figure 11] This diagram illustrates an example of multiple D2D channels (e.g., audio and data) being transmitted simultaneously. [Modes for carrying out the invention]

[0011] Next, a detailed description of exemplary embodiments will be given with reference to various figures. While this description provides detailed examples of possible modes of operation, it should be noted that the details are intended to be illustrative and not limit the scope of the application in any way. The article “is” as used herein should be understood to mean, for example, “one or more” or “at least one,” unless further limited or characterized.

[0012] Figure 1A is a diagram of an exemplary communication system 100 in which one or more disclosed embodiments may be implemented. The communication system 100 may be a multiple access system that provides content such as voice, data, video, messaging, broadcast, and others to multiple wireless users. The communication system 100 may enable multiple wireless users to access such content through the 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), quadrature FDMA (OFDMA), single-carrier FDMA (SC-FDMA), and similar.

[0013] As shown in Figure 1A, the communication system 100 may include radio transceiver units (WTRUs) 102a, 102b, 102c, and / or 102d (which may be generally or collectively referred to as WTRU 102), radio access networks (RANs) 103 / 104 / 105, core networks 106 / 107 / 109, public switched telephone network (PSTN) 108, the internet 110, and other networks 112, although it will be recognized that the disclosed embodiments intend any number of WTRUs, base stations, networks, and / or network elements. Each of the WTRUs 102a, 102b, 102c, and 102d may be any type of device configured to operate and / or communicate in a radio environment. For example, WTRUs 102a, 102b, 102c, and 102d can be configured to transmit and / or receive radio signals and may include user equipment (WTRUs), mobile stations, fixed subscriber units or mobile subscriber units, pagers, cellular phones, personal digital assistants (PDAs), smartphones, laptops, netbooks, personal computers, radio sensors, home electronic devices, and similar devices.

[0014] Furthermore, the communication system 100 may also include base stations 114a and 114b. Each of the base stations 114a and 114b may be any type of device configured to wirelessly interface with at least one of the WTRUs 102a, 102b, 102c, and 102d to facilitate access to one or more communication networks such as the core networks 106 / 107 / 109, the Internet 110, and / or network 112. For example, base stations 114a and 114b may be base station transceiver (BTS) node B, e-node B, home node B, home e-node B, site controller, access point (AP), wireless router, and similar. Although base stations 114a and 114b are shown as single elements, it will be recognized that base stations 114a and 114b may include any number of interconnected base stations and / or network elements.

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

[0016] Base stations 114a, 114b are capable of communicating with one or more of WTRUs 102a, 102b, 102c, 102d over a wireless interface 115 / 116 / 117 that can be any suitable wireless communication link (e.g., radio frequency (RF), microwave, infrared (IR), ultraviolet (UV), visible light, etc.). The wireless interface 115 / 116 / 117 can be established using any suitable radio access technology (RAT).

[0017] More specifically, as described above, the communication system 100 can be a multi-connectivity system and can use one or more channel access schemes such as CDMA, TDMA, FDMA, OFDMA, SC-FDMA, and the like. For example, base stations 114a in RANs 103 / 104 / 105, and WTRUs 102a, 102b, 102c can implement a radio technology such as Universal Mobile Telecommunications System (UMTS) Terrestrial Radio Access (UTRA) capable of establishing a wireless interface 115 / 116 / 117 using Wideband CDMA (WCDMA (registered trademark)). WCDMA can include communication protocols such as High-Speed Packet Access (HSPA) and / or Evolved HSPA (HSPA+). HSPA can include High-Speed Downlink Packet Access (HSDPA) and / or High-Speed Uplink Packet Access (HSUPA).

[0018] In another embodiment, base stations 114a and WTRUs 102a, 102b, 102c can implement a radio technology such as Evolved UMTS Terrestrial Radio Access (E-UTRA) capable of establishing a wireless interface 115 / 116 / 117 using Long-Term Evolution (LTE) and / or LTE-Advanced (LTE-A).

[0019] In other embodiments, base stations 114a and WTRUs 102a, 102b, and 102c can implement wireless technologies such as IEEE 802.16 (e.g., Worldwide Interoperability for Microwave Access (WiMAX)), CDMA2000, CDMA2000 1X, CDMA2000 EV-DO, Provisional Standard 2000 (IS-2000), Provisional Standard 95 (IS-95), Provisional Standard 856 (IS-856), Global System for Mobile Communications (GSM®), Enhanced Data Rate for GSM Evolution (EDGE), GSM EDGE (GERAN), and others.

[0020] In Figure 1A, base station 114b can be, for example, a wireless router, home node B, home enode B, or access point, and can utilize any suitable RAT to facilitate wireless connectivity in localized areas such as business locations, homes, vehicles, campuses, and similar locations. In one embodiment, base station 114b and WTRU 102c, 102d can establish a wireless local area network (WLAN) by implementing wireless technologies such as IEEE 802.11. In another embodiment, base station 114b and WTRU 102c, 102d can establish a wireless personal area network (WPAN) by implementing wireless technologies such as IEEE 802.15. In yet another embodiment, base station 114b and WTRU 102c, 102d can establish a picocell or femtocell using a cellular-based RAT (e.g., WCDMA, CDMA2000, GSM, LTE, LTE-A, etc.). As shown in Figure 1A, base station 114b can have a direct connection to the internet 110. Therefore, base station 114b may not be required to access the internet 110 via the core network 106 / 107 / 109.

[0021] RAN103 / 104 / 105 can be in communication with core networks 106 / 107 / 109, which may be any type of network configured to provide one or more voice services, data services, application services, and / or Voice over Internet Protocol (VoIP) services from WTRU102a, 102b, 102c, and 102d. For example, core networks 106 / 107 / 109 can provide call control, billing services, mobile location-based services, prepaid calls, internet connectivity, video distribution, and / or perform high-level security functions such as user authentication. Although not shown in Figure 1A, it will be recognized that RAN103 / 104 / 105, and / or core networks 106 / 107 / 109, can be in direct or indirect communication with other RANs using the same RAT as RAN103 / 104 / 105, or different RATs. For example, in addition to being connected to RANs 103 / 104 / 105 which can utilize E-UTRA radio technology, core networks 106 / 107 / 109 can also be in communication with another RAN (not shown) that uses GSM radio technology.

[0022] Furthermore, core networks 106 / 107 / 109 can also serve as gateways for WTRUs 102a, 102b, 102c, and 102d to access PSTN 108, the Internet 110, and / or other networks 112. PSTN 108 may include circuit-switched telephone networks providing ordinary conventional telephone services (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. Network 112 may include wired or wireless communication networks owned and / or operated by other service providers. For example, network 112 may include another core network connected to one or more RANs that can use the same RAT as RAN 103 / 104 / 105, or a different RAT.

[0023] Some or all of the WTRUs 102a, 102b, 102c, and 102d in the communication system 100 may include multimode capability. For example, WTRUs 102a, 102b, 102c, and 102d may include multiple transceivers for communicating with different radio networks on different radio links. For example, WTRU 102c, shown in Figure 1A, may be configured to communicate with base station 114a, which can use cellular-based radio technology, and base station 114b, which can use IEEE 802 radio technology.

[0024] Figure 1B is a system diagram of an exemplary 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, a non-removable memory 130, a removable memory 132, a power supply 134, a Global Positioning System (GPS) chipset 136, and other peripheral devices 138. It will be recognized that the WTRU 102 may include any partial combination of the aforementioned elements while remaining consistent with the embodiment. Furthermore, the embodiments intend that base stations 114a and 114b, and / or, in particular, base station transceivers (BTS), node B, site controller, access point (AP), home node B, evolved home node B (e-node B), home evolved node B (HeNB), home evolved node B gateway, and proxy node, and any other nodes that base stations 114a and 114b can represent, may include some or all of the elements shown in Figure 1B and described herein.

[0025] The processor 118 can be a general-purpose processor, a dedicated 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 similar. The processor 118 can perform signal coding, data processing, power control, input / output processing, and / or any other functions that enable the WTRU 102 to operate in a wireless environment. The processor 118 can be coupled to a transceiver 120 that can be coupled to a transmit / receive element 122. Figure 1B shows the processor 118 and the transceiver as separate components, but it will be recognized that the processor 118 and the transceiver 120 may be integrated together in an electronic package or chip.

[0026] The transmit / receive element 122 may be configured to transmit signals to or from a base station (e.g., base station 114a) on the radio 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 signals, UV signals, or visible light signals. In yet another embodiment, the transmit / receive element 122 may be configured to transmit and / or receive both RF signals and optical signals. It will be recognized that the transmit / receive element 122 may be configured to transmit and / or receive any combination of radio signals.

[0027] Furthermore, although the transmit / receive element 122 is shown as a single element in Figure 1B, the WTRU 102 can contain any number of transmit / receive elements 122. More specifically, the WTRU 102 can utilize MIMO technology. For this reason, in one embodiment, the WTRU 102 can contain two or more transmit / receive elements 122 (e.g., multiple antennas) for transmitting and receiving radio signals on the radio interfaces 115 / 116 / 117.

[0028] The transceiver 120 may be configured to modulate the signal to be transmitted by the transmitting / receiving element 122 and to demodulate the signal to be received by the transmitting / receiving element 122. As mentioned above, the WTRU 102 can have multimode capability. For this reason, the transceiver 120 may include multiple transceivers to enable the WTRU 102 to communicate via multiple RATs, such as UTRA and IEEE 802.11.

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

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

[0031] Furthermore, the processor 118 may also be coupled to a GPS chipset 136 which can 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 determine its location based on receiving location information from base stations (e.g., base stations 114a, 114b) on radio interfaces 115 / 116 / 117 and / or based on the timing of signals received from two or more nearby base stations. It will be recognized that the WTRU 102 may acquire location information by any suitable location determination method while remaining consistent with the embodiment.

[0032] The processor 118 may be further coupled to other peripheral devices 138, which may include one or more software modules and / or hardware modules that provide further features, functions, and / or wired or wireless connectivity. For example, peripheral devices 138 may include an accelerometer, an electronic compass, a satellite transceiver, a digital camera (for photography or video), 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 similar devices.

[0033] Figure 1C is a system diagram of RAN103 and core network 106 according to an embodiment. As previously mentioned, RAN103 can communicate with WTRU102a, 102b, and 102c on the radio interface 115 using UTRA radio technology. RAN103 can also be in communication with core network 106. As shown in Figure 1C, RAN103 can include nodes B140a, 140b, and 140c, each potentially containing one or more transceivers for communication with WTRU102a, 102b, and 102c on the radio interface 115. Nodes B140a, 140b, and 140c can each be associated with a specific cell (not shown) within RAN103. RAN103 can also include RNC142a and 142b. It will be recognized that RAN103 can include any number of nodes B and RNC while remaining consistent with the embodiment.

[0034] As shown in Figure 1C, nodes B140a and B140b can communicate with RNC142a. Furthermore, node B140c can communicate with RNC142b. Nodes B140a, B140b, and B140c can communicate with each other via the Iub interface. RNC142a and B142b can communicate with each other via the Iur interface. Each of RNC142a and B142b can be configured to control each of the nodes B140a, B140b, and B140c to which it is connected. Furthermore, each of RNC142a and B142b can be configured to perform or support other functions such as outer loop power control, load control, acceptance control, packet scheduling, handover control, macro diversity, security functions, data encryption, and similar.

[0035] The core network 106 shown in Figure 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. While each of the aforementioned elements is shown as part of the core network 106, it should be noted that any one of these elements may be owned and / or operated by an entity other than the core network operator.

[0036] RNC142a in RAN103 can be connected to MSC146 in core network 106 via the IuCS interface. MSC146 can be connected to MGW144. MSC146 and MGW144 can provide WTRU102a, 102b, and 102c with access to circuit-switched networks such as PSTN108, thereby facilitating communication between WTRU102a, 102b, and 102c and conventional land-line communication devices.

[0037] Furthermore, RNC142a in RAN103 can also be connected to SGSN148 in core network 106 via the IuPS interface. SGSN148 can be connected to GGSN150. SGSN148 and GGSN150 can provide WTRU102a, 102b, and 102c with access to packet-switched networks such as the Internet 110, thereby facilitating communication between WTRU102a, 102b, and 102c and IP-enabled devices.

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

[0039] Figure 1D is a system diagram of RAN104 and core network 107 according to an embodiment. As mentioned above, RAN104 can communicate with WTRU102a, 102b, and 102c on the wireless interface 116 using E-UTRA wireless technology. RAN104 can also be in communication with core network 107.

[0040] RAN104 may include enodes B160a, 160b, and 160c, although it will be recognized that RAN104 may include any number of enodes B while remaining consistent with the embodiment. Each of enodes B160a, 160b, and 160c may include one or more transceivers for communicating with WTRU102a, 102b, and 102c on the radio interface 116. In one embodiment, enodes B160a, 160b, and 160c are capable of performing MIMO technology. For example, enode B160a may use multiple antennas to transmit radio signals to and from WTRU102a.

[0041] Each of the e-nodes B160a, 160b, and 160c can be associated with a specific cell (not shown) and can be configured to handle radio resource management decisions, handover decisions, user scheduling on uplink and / or downlink, and similar matters. As shown in Figure 1D, the e-nodes B160a, 160b, and 160c can communicate with each other over the X2 interface.

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

[0043] The MME162 can be connected to each of the e-nodes B160a, 160b, and 160c in RAN104 via the S1 interface and can act as a control node. For example, the MME162 can be responsible for authenticating users of WTRU102a, 102b, and 102c, bearer activation / deactivation, selecting a specific serving gateway during the initial attachment of WTRU102a, 102b, and 102c, and similar tasks. The MME162 can also provide control plane functionality for switching between RAN104 and other RANs (not shown) using other radio technologies such as GSM or WCDMA.

[0044] The serving gateway 164 can be connected to each of the e-nodes B160a, 160b, and 160c in RAN104 via the S1 interface. The serving gateway 164 is generally capable of routing and forwarding user data packets to and from WTRU102a, 102b, and 102c. The serving gateway 164 can also perform other functions such as anchoring the user plane during e-node B handover, triggering paging when downlink data is available to WTRU102a, 102b, and 102c, managing and remembering the context of WTRU102a, 102b, and 102c, and similar functions.

[0045] Furthermore, the serving gateway 164 can also be connected to the PDN gateway 166, which provides WTRU 102a, 102b, and 102c with access to packet-switched networks such as the Internet 110, thereby facilitating communication between WTRU 102a, 102b, and 102c and IP-enabled devices.

[0046] The core network 107 can facilitate communication with other networks. For example, the core network 107 can provide WTRU 102a, 102b, and 102c with access to circuit-switched networks such as PSTN 108, thereby facilitating communication between WTRU 102a, 102b, and 102c and conventional land-line communication devices. For example, the core network 107 can include or communicate with an IP gateway (e.g., an IP Multimedia Subsystem (IMS) server) that acts as an interface between the core network 107 and PSTN 108. Furthermore, the core network 107 can provide WTRU 102a, 102b, and 102c with access to network 112, which may include other wired or wireless networks owned and / or operated by other service providers.

[0047] Figure 1E is a system diagram of RAN105 and core network 109 according to an embodiment. RAN105 can be an access service network (ASN) that communicates with WTRU102a, 102b, and 102c over a wireless interface 117 using IEEE 802.16 wireless technology. As will be further described later, communication links between different functional entities of WTRU102a, 102b, 102c, RAN105, and core network 109 can be defined as reference points.

[0048] As shown in Figure 1E, RAN105 may include base stations 180a, 180b, and 180c, and an ASN gateway 182, although it will be recognized that RAN105 may include any number of base stations and ASN gateways while remaining consistent with the embodiment. Each of the base stations 180a, 180b, and 180c may be associated with a specific cell (not shown) in RAN105, and each may include one or more transceivers for communicating with WTRU102a, 102b, and 102c on the radio interface 117. In one embodiment, the base stations 180a, 180b, and 180c may perform MIMO technology. For example, base station 180a may use multiple antennas to transmit radio signals to and receive radio signals from WTRU102a. Furthermore, base stations 180a, 180b, and 180c can also provide mobility management functions such as handoff triggering, tunnel establishment, radio resource management, traffic classification, quality of service (QoS) policy enforcement, and similar functions. The ASN gateway 182 can act as a traffic aggregation point and is capable of paging, subscriber profile caching, routing to the core network 109, and similar functions.

[0049] The radio interface 117 between WTRU102a, 102b, 102c and RAN105 may be defined as an R1 reference point that implements the IEEE 802.16 standard. Furthermore, each of WTRU102a, 102b, and 102c can establish a logical interface (not shown) with the core network 109. The logical interface between WTRU102a, 102b, 102c and the core network 109 may be defined as an R2 reference point that can be used for authentication, authorization, IP host configuration management, and / or mobility management.

[0050] The communication links between base stations 180a, 180b, and 180c may be defined as R8 reference points, which include protocols for facilitating WTRU handover and data transfer between base stations. The communication links between base stations 180a, 180b, and 180c and the ASN gateway 182 may be defined as R6 reference points. R6 reference points may include protocols for facilitating mobility management based on mobility events associated with WTRUs 102a, 102b, and 102c, respectively.

[0051] As shown in Figure 1E, RAN 105 may be connected to core network 109. The communication link between RAN 105 and core network 109 may be defined as an R3 reference point, for example, containing protocols for facilitating data transfer and mobility management capabilities. Core network 109 may include a mobile IP phone agent (MIP-HA) 184, an authentication, authorization, and accounting (AAA) server 186, and a gateway 188. While each of the aforementioned elements is shown as part of core network 109, it should be noted that any one of these elements may be owned and / or operated by an entity other than the core network operator.

[0052] MIP-HA can handle IP address management and enable WTRU102a, 102b, and 102c to roam between different ASNs and / or different core networks. MIP-HA184 can provide WTRU102a, 102b, and 102c with access to packet-switched networks such as the Internet 110, thereby facilitating communication between WTRU102a, 102b, and 102c and IP-enabled devices. AAA server186 can handle user authentication and support user services. Gateway188 can facilitate interworking with other networks. For example, gateway188 can provide WTRU102a, 102b, and 102c with access to circuit-switched networks such as PSTN108, thereby facilitating communication between WTRU102a, 102b, and 102c and conventional landline communication devices. Furthermore, gateway 188 can provide WTRU 102a, 102b, and 102c with access to network 112, which may include wired or wireless networks owned and / or operated by other service providers.

[0053] Although not shown in Figure 1E, it will be recognized that RAN105 can be connected to other ASNs, and core network 109 can be connected to other core networks. The communication links between RAN105 and those other ASNs may be defined as R4 reference points that can include protocols for coordinating the mobility of WTRU102a, 102b, and 102c between RAN105 and those other ASNs. The communication links between core network 109 and those other core networks may be defined as R5 reference points that can include protocols for facilitating interworking between the home core network and the destination core network.

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

[0055] PS applications may need (or require) wireless communication in areas that may not be under the wireless coverage of an LTE network, such as in tunnels, deep underground rooms, and / or after a catastrophic system failure. Therefore, there may be a usefulness in supporting D2D communications for PS in situations where there is no working network and / or prior to the arrival of a temporarily deployed wireless infrastructure. Even when operating in the presence of a working network infrastructure, PS communications may need (or require) higher reliability than civilian services.

[0056] For example, a PS-type application between first responders can include a direct push-to-talk voice service using multiple talk groups. PS-type applications can also include services such as video push or video download, which efficiently utilize the capabilities provided by LTE broadcast radio.

[0057] D2D communication may be available for PS-type applications and / or civilian use cases, for example, when deployed. For example, a civilian use case could be a utility company that also frequently requires support for two-way wireless communication in areas not covered by the network infrastructure. D2D services such as discovery are a suitable signaling mechanism that enables proximity-based services and / or traffic offloading using LTE-based wireless access in civilian use cases.

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

[0059] In an LTE system, it is possible to have an access control mechanism and / or priority processing mechanism that mediates terminal access to and / or use of radio resources.

[0060] For example, a System Information Broadcast (SIB) message carried over a Broadcast Channel (BCH) can carry information about which access service class a terminal attempting to connect to a cell is permitted to use, e.g., emergency only, maintenance only, and / or any other type. Access control may be possible, for example, when a terminal device connects to an LTE cell. For example, if more terminals that can be reliably supported are connected to a cell, access layer (AS) connections and / or non-access layer (NAS) connections may be terminated from the network side. Terminal devices may be redirected to channels and / or banks of other radio access technologies in the operator's network, such as GSM or 3G HSPA.

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

[0062] LTE systems can provide techniques for prioritizing simultaneously running wireless services. Prioritization can be used to ensure that higher quality of service (QoS) data streams, such as conversational voice and video, can be served earlier and / or at a guaranteed bitrate or guaranteed latency. Prioritization can also be used to serve control signaling (e.g., useful / essential control signaling) (e.g., serve it earlier).

[0063] For example, in an LTE system, prioritizing data with multiple users in the system may be possible by the base station scheduling high-priority data with real-time QoS constraints on the downlink (DL) (e.g., earlier). Prioritizing data with multiple users in the system may also 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, for example, the system can perform priority processing for E911 calls to ensure a much higher success call setup percentage and / or a much lower occurrence of dropped calls compared to what is normally guaranteed for normal voice calls. When a single terminal device has multiple types of data to transmit simultaneously, rules can specify that higher-priority data be transmitted (e.g., earlier) when a UL transmission opportunity is permitted. Lower-priority data can be completed (e.g., later) once packets assigned to a higher logical channel priority have completed their transmission.

[0064] Prioritization from a single user's perspective, and / or from a system perspective, can be implemented in different forms within existing LTE systems. These may share the commonality that higher-priority data can be transmitted (e.g., earlier) if it is useful, and / or lower-priority data can be preempted if simultaneous services must be supported at the same time.

[0065] D2D communication can use LTE-based wireless access.

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

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

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

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

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

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

[0072] D2D discovery may or may not use the same or similar channel access protocols, such as those used for D2D communications on voice and / or general D2D data. With respect to D2D discovery services, such as when within LTE base station coverage, D2D discovery resources may be allocated from those used for D2D communications with voice or general D2D data (e.g., separately allocated). Radio resources for D2D discovery messages may be reserved by the eNB and / or be recurring (e.g., periodically recurring) time-frequency radio resources in UL subframes (e.g., type 1 discovery) and / or may be selected by the D2D terminal (e.g., autonomously) from a set of resources that can be allocated (e.g., explicitly allocated) to the D2D terminal (e.g., type 2 discovery) by the LTE serving cell. The latter may be similar to D2D communication mode 1. Sending scheduling allocations may not be used when sending D2D discovery messages. A D2D terminal that sends a D2D discovery message (for example, sending only that) may be used to send an auxiliary D2D synchronization signal to assist the receiver.

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

[0074] D2D terminals, such as those intended for use in public safety applications, may be designed (e.g., inherently) to operate in situations where there is no operating LTE radio network infrastructure. This may mean that these devices may be able to operate automatically with respect to any processing of channel access and D2D data transmission. Unlike current LTE terminal devices, which are generally network-controlled via control signaling message exchange with the LTE network, D2D terminal devices may be able to store (e.g., usually store) several (e.g., most, if not all) parameters as part of application software (SW) that can determine their channel access behavior and / or transmission behavior on the (U)SIM card.

[0075] Transmit procedures and / or channel access protocols for D2D communications using LTE-based radio access may not be designed to allow random access with priority distinctions for individual devices and / or to enable data transmission that takes quality of service (QoS) for D2D data into consideration. Mechanisms may exist to deny, limit, and / or restrict access to D2D radio resources for specific devices or users.

[0076] For example, in a scenario in particular where an LTE cell is within range, some limitations may be imposed by the LTE serving cell on the acceptable UL subframes that can be reserved for use by nearby D2D terminals. Prioritization and channel access for different types of data transmitted by different users or from a given D2D user may not be deterministically guaranteed. If D2D radio resources in an LTE serving cell are over-provisioned (e.g., only in such cases), successful channel access for high-priority terminals and successful transmission of higher-priority data can be guaranteed, for example, statistically. In situations where there is no 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 respect to wireless resource allocation tradeoffs.

[0078] D2D communications using LTE-based radio access may allow for (e.g., implicit) distinction between different types of received D2D communications, for example, if the transmitting device associates an encryption key or message integrity protection key used by the D2D SW application to secure the D2D data payload with a D2D service identifier. If the key and identifier are known, a transmitting or receiving D2D terminal may not be able to distinguish between higher-priority users and / or higher-priority types of D2D data until, for example, it is possible to demodulate (e.g., physically) and / or decrypt any such D2D transmission. D2D devices may not take into account the priority of ongoing and / or planned D2D communications when determining their own transmitting and / or receiving behavior. A D2D terminal 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 a situation where critical D2D communications are ongoing. A D2D terminal may not be configured (for example, never) possess knowledge of one or more D2D identifiers, or all D2D identifiers, and / or associated derived payload encryption keys and / or message integrity protection keys that may be used nearby by other D2D terminals. This means that one or more (for example, most) D2D terminals may be indifferent to the type and / or category of D2D data they attempt to decrypt and distinguish based on the received D2D payload content. A payload may not be decrypted by such a D2D device in the absence of trusted keys and / or associated identifiers. Information about the D2D payload being carried may not be derived.

[0079] Mechanisms for D2D communications using LTE radio access technology that can enable priority-based channel access, priority-based processing of D2D communications as a function of D2D terminals and / or D2D data types to ensure service availability and QoS, and / or preemption in critical situations may be described herein. The availability of priority-based access mechanisms and / or transmission mechanisms can enhance the efficiency of radio transmission, 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 can refer to D2D-related communications between D2D terminals. For example, without loss of generality, D2D data can include data packets such as those carrying voice or segments thereof, IP packets or segments thereof used for file downloads or uploads, streaming video or two-way video, D2D control signaling, or D2D discovery or D2D service or D2D availability messages, etc. The features disclosed herein can be described in the general context of 3GPP D2D communications, and the features may be applicable to other features such as D2D discovery.

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

[0082] Priority-based access for D2D communication can utilize a segregated set of radio resources in the time domain and / or frequency domain.

[0083] A segregated set of radio resources in the time domain and / or frequency domain for use with preferred D2D access may be implemented on radio resources that can be used for scheduling allocation (SA), D2D data, D2D control, or D2D service signaling such as D2D discovery, for one of these D2D data signals / channels, and / or for multiple of these D2D data signals / channels.

[0084] Figure 2 illustrates priority-based access via TDM in SA and D2D data subframes. Priority-based access for D2D communication can be achieved via time-division multiplexing (TDM) of SA and / or D2D data pools.

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

[0086] An SA pool (e.g., the first SA pool in Figure 2) can 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) over the duration of the scheduling cycle. High-priority transmissions can correspond to responder talk groups (e.g., initial responder talk groups) and / or high-priority voice channels. An SA pool (e.g., the second SA pool in Figure 2) can carry SAs for corresponding lower-priority D2D transmissions in a D2D data pool (e.g., the second D2D data pool). Lower-priority transmissions may be background file downloads of D2D service data and / or non-time-critical exchanges.

[0087] High-priority D2D data transmissions may occur on (e.g., only on) radio resources used by SAs (e.g., the first SA in Figure 2) and / or the corresponding D2D data pools (e.g., the first D2D data pool in Figure 2). Low-priority D2D data transmissions may occur on (e.g., only on) radio resources used for SAs (e.g., the second SA) and / or D2D data pools (e.g., the second D2D data pool). SAs carried in subframes of high-priority (e.g., the first) SA pools may not announce D2D data on radio resources relating to low-priority (e.g., the second) D2D data pools. SAs carried in subframes of low-priority (e.g., the second) SA pools may not announce D2D data on radio resources relating to high-priority (e.g., the first) D2D data pools.

[0088] TDM in lower-priority D2D transmissions may not be performed on higher-priority SA / data pools, which can improve priority processing for D2D transmissions. For network-controlled radio resource allocation of SA and / or D2D data on high-priority pools, low-priority D2D devices and channels may not compete for segregated TDM radio resources. For WTRU autonomous conflict resolution on such SA / data resources, low-priority D2D devices and channels may not compete for segregated TDM radio resources. For random radio resource selection of SA / data by D2D terminals, low-priority D2D devices and channels may not compete for segregated TDM radio resources. Higher-priority D2D data may have a (considerably) higher probability of being successfully transmitted during the initial determination of radio resources and / or during ongoing transmission, due to reduced interference from lower-priority D2D data. Legacy D2D terminals that cannot prioritize processing may be prevented from accessing new, higher-priority SAs / data pools through resource segregation.

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

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

[0091] An SA pool (for example, the first SA pool in Figure 3) can carry SAs for associated high-priority D2D data transmissions. An SA pool (for example, the second SA pool in Figure 3) can carry SAs for associated lower-priority D2D data transmissions.

[0092] High-priority D2D data transmissions can be transmitted by (e.g., simply by) using radio resources from the high-priority SA pool (the first SA pool). Lower-priority D2D data transmissions can be transmitted by (e.g., simply by) using radio resources from the lower-priority SA pool (the second). SAs from the high-priority SA pool (e.g., the first SA pool) and / or the lower-priority SA pool (e.g., the second) can correspond to D2D data transmitted over the shared radio resources of the D2D data pool.

[0093] Prioritization for D2D transmissions can be improved. For example, priority processing for D2D transmissions can be improved if lower-priority D2D transmissions cannot be performed on higher-priority SA pools. For network-controlled radio resource allocation of SAs on high-priority pools, low-priority D2D devices and channels can avoid competition for such isolated TDM radio resources. For WTRU autonomous contention resolution on such SA resources, low-priority D2D devices and channels can avoid competition for such isolated TDM radio resources. For random radio resource selection determining SAs by D2D terminals, low-priority D2D devices and channels can avoid competition for such isolated TDM radio resources. Higher-priority D2D data may have a (e.g., considerably) higher probability of being transmitted, for example, to avoid interference and / or contention on SA radio resources. Priority-based access mechanisms can be implemented while maintaining the principles and / or resource utilization (e.g., intrinsic resource utilization) efficiency of shared D2D data pools.

[0094] Figure 4 illustrates priority-based access for D2D communication via FDM in SA and D2D data subframes. Priority-based access for D2D communication can be achieved via frequency division multiplexing (FDM) of SA and D2D data pools.

[0095] In the example in Figure 4, there is an N=1 SA pool in the time domain and a corresponding D2D data pool with M=1 in the time domain. In Figure 4, there are L1=2 subframes for each SA in the SA pool per scheduling period of P=160 milliseconds. In Figure 4, there are L2=38 available subframes in the D2D data pool per scheduling period. The radio resources in the SA pool encompass L2=2 different and separate radio block subsets in the frequency domain. A subframe containing an SA can contain SAs for high-priority D2D data transmissions in RB10-30 and SAs for low-priority D2D data in RB40-60. A subframe containing D2D data can contain high-priority transmissions and / or low-priority transmissions in RB10-30 and RB40-60 (e.g., only in those) (e.g., respectively). These can be referred to as the SA data pool and D2D data pool in the frequency domain.

[0096] A frequency-domain SA pool (e.g., the first frequency-domain SA pool in Figure 4) can carry SAs for associated high-priority D2D data transmissions in a frequency-domain D2D data pool (e.g., the first frequency-domain D2D data pool in Figure 4) over the duration of the scheduling period. A frequency-domain SA pool (e.g., the second frequency-domain SA pool in Figure 4) can carry SAs for associated lower-priority D2D transmissions in a frequency-domain D2D data pool (the second frequency-domain D2D data pool in Figure 4).

[0097] High-priority D2D data transmissions can occur over (e.g., only over) radio resources in the frequency domain, such as the frequency domain used by SAs (e.g., the first SA) and / or the corresponding D2D data pool (e.g., the first D2D data pool). Lower-priority D2D data transmissions can occur over (e.g., only over) radio resources used for SAs (e.g., the second SA) and / or data pools (e.g., the second data pool) in the frequency domain. For example, an SA carried in a subframe of the high-priority SA frequency domain (e.g., the first SA frequency domain) may not advertise D2D data over radio resources used in the low-priority D2D data (e.g., the second D2D data) frequency domain. An SA carried in the low-priority frequency domain SA domain may not advertise D2D data over radio resources in the high-priority D2D data frequency domain (e.g., the first D2D data frequency domain).

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

[0099] Figure 5 illustrates 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 an SA pool while using a shared D2D data pool.

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

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

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

[0103] Prioritization for D2D transmissions can be improved. For example, priority processing for D2D transmissions can be improved if lower-priority D2D transmissions can be prevented from occurring on higher-priority SA radio resources in the frequency domain. For network-controlled radio resource allocation to SAs on high-priority pools, low-priority D2D devices and / or low-priority channels can avoid competition for such isolated FDM radio resources. For contention resolution on such SA resources, low-priority D2D devices and / or low-priority channels can avoid competition for such isolated FDM radio resources. For random radio resource selection determining SAs by D2D terminals, low-priority D2D devices and low-priority channels can avoid competition for such isolated FDM radio resources. Higher-priority D2D data may have a higher (e.g., considerably higher) probability of being transmitted to avoid interference and / or contention on SA radio resources. Priority-based access mechanisms can be implemented while maintaining the principles of a shared D2D data pool and / or resource utilization (e.g., intrinsic resource utilization) efficiency.

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

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

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

[0107] The opportunity to send may be determined, for example, by the following:

[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. The controlling device can be a D2D terminal and / or an LTE radio network device such as a base station.

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

[0110] Controlling devices can signal their radio resource sets (e.g., explicitly) by using a shared control channel such as a BCH broadcast channel or a PD2DSCH broadcast channel. For example, system information on a BCH can include one or both of a subframe number or subframe set, or a combination of associated frequency resources combined with an access priority level. Such D2D access levels and / or priority levels can be given (e.g., explicitly). Such D2D access levels and / or priority levels can be derived (e.g., implicitly) based on the order in which they may be communicated. Such D2D access levels and / or priority levels can 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 can be derived by a D2D terminal, for example, by observing and / or decoding known transmission formats and / or reference signals.

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

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

[0114] For example, such a reference signal could be the occurrence of a timing-acquiring signal and / or frequency-acquiring signal such as D2DSS, DL Sync signal, or PD2DSCH. A receiving D2D terminal can determine the occurrence of such a reference signal. A receiving D2D terminal can calculate the expected occurrence in the time domain of a transmission opportunity for high-priority D2D data or low-priority D2D data. Timing relationships can be performed and / or given via an expression, for example, using an index or counter representing time as one parameter, such as SFN. Timing relationships can be given by a bitmap and / or a table of values. For example, a high-priority D2D transmission opportunity could be given every 8th and 9th subframe, starting from the measured occurrence of D2DSS from the transmitter, while a low-priority D2D transmission opportunity could 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 can be based on the use of wireless 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 domain and / or frequency domain, where RRPTs for use with high-priority or low-priority D2D data may be characterized by different allocation densities in the time / frequency domain over a given time period.

[0118] Preferred D2D access using different radio resource transmission patterns may be implemented on radio resources used for control signaling or service signaling such as scheduling assignment (SA), data, and D2D discovery, with respect to any one of the D2D data signals / channels, or with respect to one or more (e.g., several) of these D2D data signals / channels.

[0119] Figure 6 illustrates priority-based access via different resource allocation densities for a D2D subframe pool, such as TDM. In Figure 6, a different number of subframes per scheduling cycle can be allocated and / or configured with time-domain isolated resources for SA and D2D data (e.g., for high-priority and low-priority D2D data, respectively).

[0120] In Figure 6, a Radio Resource Transmission (e.g., a first Radio Resource Transmission) pattern (RRTP) can be configured for high-priority D2D data, allowing 31 D2D data subframes per 160-millisecond scheduling period, while a (e.g., second) RRTP can be used for low-priority D2D data, allowing 15 subframes per scheduling period.

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

[0122] Prioritization for D2D transmissions can be improved, for example, in that lower-priority D2D transmissions may take longer to complete than higher-priority D2D data transmissions, with respect to the same resource utilization efficiency per D2D transmission. High-priority D2D data transmissions can utilize more resource allocation space (e.g., "larger pipes") in time and / or frequency, which can improve the time it takes them to complete transmissions and / or improve their observable signal-to-noise and / or interference ratio (SINR) when compared to (e.g., a second) lower-priority SA and low-priority D2D data pools.

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

[0124] The example shown in Figure 6 can be adjusted, for example, by allowing the radio resource density in time to be adjusted for different transmission characteristics that may be expected with respect to high-priority SAs (e.g., the first high-priority SA in Figure 6) and D2D data pools, compared to those used for low-priority D2D (e.g., the second low-priority D2D in Figure 6) transmission opportunities. For example, if high-priority D2D data consists primarily of voice broadcast channels occupying 3 PRBs per subframe, where a total of 5 transmissions every 20 milliseconds can be used to maintain an operational SINR of 0-1 dB for BLER at a target level of 2-4%, while low-priority D2D data consists of D2D discoveries using 2 PRBs and without repetition to achieve detection reliability for an operational SINR of 5 dB, then the SA and data pool (e.g., the first SA and data pool) may be oversized in a sequential approach (e.g., the first sequential approach), such as by taking into account (e.g., only taking into account) the expected number of retransmissions for identical or similar amounts of traffic being provided, adjusted by the over-provisioning factor for higher-priority traffic as desired.

[0125] Figure 7 illustrates priority-based access via different resource allocation densities (e.g., transmission parameters). In Figure 7, a different number of subframes per scheduling cycle may be used by the D2D terminal with time-domain isolated resources for SA and D2D data, for example, while transmitting high-priority D2D data and low-priority D2D data (e.g., respectively).

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

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

[0128] High-priority RRTPs (e.g., the first RRTP in Figure 7) and / or low-priority RRTPs (e.g., the second RRTP in Figure 7) can be allocated different amounts of radio resources per time period, such as one scheduling cycle.

[0129] Prioritization for D2D transmissions can be improved, for example, by ensuring that lower-priority D2D transmissions take longer to complete than higher-priority D2D data transmissions, with respect to the same resource usage efficiency per D2D transmission. D2D transmitter devices can, for example, select (e.g., autonomously) the amount of radio resources used to transmit D2D data corresponding to cases of high-priority D2D data versus low-priority D2D data. A shared D2D data pool can be used to improve resource utilization and efficiency.

[0130] In Figure 7, the time-multiplexed SA and D2D data resources can be extended to frequency domain allocations for RRPT applied to SA and D2D data pools.

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

[0132] The examples described herein (for example, relating to Figures 6 and 7) can be extended to cases of more than two priority classes having SAs or data pools in the time domain or frequency domain. For example, an N=M=4 priority category corresponding to four different separate radio resource transmission patterns may be used. Different scheduling period lengths may be used. SA transmissions can correspond to D2D data transmitted in later scheduling periods and / or multiple scheduling periods. Independent of or in conjunction with scheduling periods, the principle of semi-persistent, time-limited, or dynamically permitted D2D data transmission can be used together with the aforementioned principle of different radio resource transmission densities per time period. Although the examples used SAs and D2D data for illustrative purposes, the principle of radio resource transmission density per time period can be similarly described when different D2D channels or different signaling messages are used 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 the controlling device. RRPTs for use with high-priority or low-priority D2D data can 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 radio network device, such as a base station.

[0134] The controlled device can signal a set of radio resources (e.g., a first set of radio resources) having a time period-based radio resource allocation density (e.g., a first set of radio resources) for use in high-priority D2D data transmissions. The controlled device can also signal a set of radio resources (e.g., a second set of radio resources) having a different time period-based radio resource allocation density (e.g., a second different set of radio resources) for use in lower-priority D2D data transmissions.

[0135] The controlling devices can signal their radio resource sets (e.g., explicitly) by using a shared control channel, such as a BCH broadcast channel or a PD2DSCH broadcast channel. System information on the BCH can include one or both of the subframe number or subframe set, or combinations of associated frequency resources combined with an access priority level. Such D2D access levels and priority levels can be given (e.g., explicitly), derived (e.g., implicitly) in 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, such as RRPTs for use with high-priority D2D data or low-priority D2D data being characterized by different allocation densities in the time / frequency domain over a predetermined time period.

[0137] A D2D transmitter device intended to transmit D2D data can determine (for example, first) whether the D2D data corresponds to a high-priority data category or a low-priority data category. The D2D transmitter can, for example, determine the corresponding SA and / or data radio resources to be used for the D2D data transmission as a result of the priority determination. The D2D transmitter device can 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 different allocation densities in the time / frequency domain over a given time period. The D2D transmitter can transmit the SA and / or D2D data over the determined radio resources. Transmission of SA and D2D data can be terminated, for example, if there is no more data to transmit. Re-evaluation and / or determination of appropriate radio resources may occur, for example, if there are changes to the radio resources allowed for high-priority or low-priority SAs, or if a new scheduling period begins.

[0138] A D2D receiver intended to decode D2D data can determine SA and / or data radio resources. The D2D receiver can determine whether high-priority D2D transmissions or low-priority D2D transmissions can be received on the corresponding radio resources. The D2D receiver can determine a radio resource transmission pattern (RRTP) that can represent the access priority of D2D data, such as being indicated, decoded, or derived from D2D signal transmissions. As a function of the RRTP, the D2D receiver can attempt to decode and / or demodulate at least a subset of the radio resources, for example, as a function of the determined parameters.

[0139] Different radio resource transmission patterns (RRPTs) for D2D data using preferred access may be determined, for example, by the transmitting D2D terminal from a timing relationship. RRPTs for use with high-priority or low-priority D2D data can be characterized, for example, by different allocation densities in the time / frequency domain over a given time period.

[0140] For example, when timing parameters are determined using reference signals, these may be the generation of timing signals and / or frequency acquisition signals such as D2DSS, DL Sync signals, or PD2DSCH. A transmitting D2D terminal can determine an RRPT (e.g., a first RRPT), such as a baseline pattern relating to the generation of the timing reference. A transmitting D2D terminal can determine a tuned RRPT (e.g., a second tuned RRPT) for use for its D2D transmission by, for example, using the determined RRPT as an input (e.g., a first input) and a parameter indicating whether the D2D data is high-priority or low-priority as an input (e.g., a second input). Timing relationships can be performed or given via expressions that use indices or counters representing time as one or more parameters, such as an SFN. Timing relationships can be given by a bitmap of values ​​or a table of sets of values. For example, a high-priority D2D transmit opportunity could be determined from a baseline RRPT pattern that results in a transmit every fourth subframe, starting from a measured occurrence of D2DSS from the transmitter, while a low-priority D2D transmit opportunity could be determined every twelfth subframe (for example, only), offset by only three subframes from the first D2DSS occurrence.

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

[0142] The access mechanism allows for the use of guaranteed isolated resources for high-priority devices.

[0143] Priority access can be achieved by guaranteeing and / or potentially reserving a set of resources that may be used by higher-priority data transmissions. These resources may correspond to a set of time / frequency resources (e.g., including a set of patterns) for SAs and / or data pools. Higher-priority WTRUs may have guaranteed access to these resources, while lower-priority WTRUs may use the higher-priority reserved data resources, for example, if those resources are not being used by higher-priority data.

[0144] SA resource pools can be isolated 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 could correspond to subframes that can be used by (e.g., only by) devices that transmit high-priority data and / or devices that may be high-priority devices.

[0145] A WTRU can monitor resources (e.g., SA resources / subframes) configured for sending data with a higher priority than the data available in the WTRU. A WTRU can monitor subframes reserved for sending higher-priority data.

[0146] If a WTRU determines that at least X (for example, X can be a configurable number) higher priority scheduling occurrences can be detected on higher priority SA resources (e.g., in the current or past scheduling cycle across a predefined window), the WTRU may transmit lower priority data on (e.g., only on such resource pools) resource pools reserved / configured for lower priority data. If a WTRU determines that at least X higher priority scheduling occurrences can be detected on higher priority SA resources, the WTRU may transmit (e.g., only in this manner) using one or more (e.g., one) RRPTs selected from a list of RRPTs to be used for lower priority data, or configured for the priority level of data available for transmission. This ensures that if at least one high priority data transmission exists, a lower priority WTRU will not attempt to use resources intended for higher priority data. If scheduling occurrences less than X are detected, the WTRU may select resources from data resource pools configured for higher priority data and lower priority data. If a scheduling event less than X is detected, the WTRU can select from a list of RRPTs reserved for higher-priority and lower-priority data.

[0147] A WTRU can decode SAs transmitted over high-priority SA resources (for example, first) and determine the set of resources or RRPTs used by the high-priority data. The WTRU can then exclude the set of resources or RRPTs used by the high-priority data from the list of available RRPTs or resources it will use. This allows a WTRU transmitting lower-priority data to utilize resources that would otherwise be unavailable for transmitting higher-priority data.

[0148] Four SA subframes may be configured for D2D transmissions at 80-millisecond scheduling intervals. A set of SA subframes 1-4 (e.g., the complete set) may be used by a WTRU for transmission and / or reception, for example, for high-priority D2D data. A subset of SA subframes 3-4 may be used by a WTRU for low-priority D2D data (e.g., only a subset of SA subframes 3-4 may be used by a WTRU for low-priority D2D data). A WTRU can determine (e.g., in advance) whether the D2D data it must transmit is high-priority or low-priority D2D data. If a WTRU determines that its D2D data is low-priority, it can determine whether high-priority D2D transmissions by other WTRUs are announced in relation to the scheduling interval by decoding SAs in the four available SA subframes. If it finds such high-priority SAs, it can extract the decoding information and / or determine the transmission parameters corresponding to these high-priority SAs. A WTRU can determine the set of D2D SAs and corresponding D2D data subframes that are currently in use by other high-priority WTRUs. The WTRU can then select SAs and / or D2D data resources that are not in use by the determined high-priority WTRUs (e.g., all determined high-priority WTRUs) and transmit its own SAs. If no available SAs and / or D2D data resources are found, the transmission may be postponed. For example, as mentioned above, if a WTRU determines that its D2D data is high-priority, it can select available SAs and corresponding D2D data resources for its own transmission (e.g., any available SAs and corresponding D2D data resources for its own transmission).

[0149] In one or more techniques described herein, if, for example, in a scenario in particular, the number of high-priority WTRU transmissions decoded by a low-priority WTRU may be greater than some value N, the low-priority WTRU may have behavior using one or more of the following: Sending over a different SA pool and / or data pool within the same scheduling period. Using the same SA pool, but sending data over a different data pool within the same scheduling cycle. Transmit using the same SA and / or data pool in the same scheduling period, but using TRPT and / or time-frequency resources for SAs that are not used by any of the high-priority WTRUs. Reduce the transmit power in the current scheduling cycle. Postpone transmission to the next scheduling cycle and / or at a random time in the future, and / or A retransmission timer is started, and in some techniques, after the timer has expired, the WTRU may retry one or more of the aforementioned scenarios, among others.

[0150] In some embodiments, for example, with respect to SA resources in particular, in some scenarios, it is possible that SA subframes available for high priority may occur (partially or completely) earlier in time (e.g., compared to low-priority SAs) to avoid SA resource conflicts and / or to enable SA resources to be more easily accessed by high-priority users. SA resources associated with high-priority WTRUs and / or associated with low-priority WTRUs can be configured in WTRUs via signaling (e.g., by being assigned to different SA pools) and / or can 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 index). 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, it is possible for a first N1 time-frequency block that can be selected by a high-priority WTRU to occur prior in time to a first N2 time-frequency block that can be selected by a low-priority WTRU (e.g., it can always occur). That is, while it is possible for N1 for the high-priority WTRU to be in the set 0 < N1 < K1, it is possible for N2 for the low-priority WTRU to 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 does not 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 numbered and / or indexed RB / subframe time-frequency resources. 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, of 150 indexed 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, of 120 indexed RB / subframe time-frequency resources.In some 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 resources, it may be able to utilize SA resources in the 120 indexed low-priority RB / subframe time-frequency resources.

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

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

[0156] Using the features described herein, high-priority D2D transmissions can have preferential access (e.g., first access) to configured and / or available D2D transmission resources. Low-priority D2D transmissions can be selected as these functions and can be transmitted if the D2D transmission resources are still available. Given that a WTRU can decode incoming SAs in SAs carrying subframes to determine whether they are capable of receiving the corresponding D2D data as part of a monitored talk group, it is possible to determine which D2D transmission resources are occupied using the available information obtained from decoding the SAs with little additional decoding complexity.

[0157] In some embodiments, certain resources can be reserved for high-priority transmissions, and / or high-priority WTRUs can transmit occupancy flags to low-priority WTRUs indicating that they can use data resources related to high-priority SAs and / or a given scheduling period. Occupancy flags can be transmitted as part of an SA (e.g., at the beginning of an SA), and / or in an SA prior to a target scheduling period, possibly indicating, for example, the occupancy of one or more SA resources in one or more future scheduling periods. Occupancy flags can be transmitted in separate channels (e.g., D2DSS and / or PD2DSCH) that can be read by one or more, or all, D2D WTRUs. Flags can be associated with (e.g., a 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 may be configured for D2D transmission every 80 milliseconds scheduling period. An occupancy flag (e.g., a single one) associated with subframes 1 and 2 may be set whenever a higher priority WTRU is able to utilize any of these subframes. A lower priority WTRU may wish to transmit an SA and / or (e.g., subsequently) data. A WTRU may check for the presence of the occupancy flag to determine, for example, whether there is a higher priority WTRU planning to transmit an SA for that scheduling period. In particular, if the occupancy flag is set, the lower priority WTRU may utilize subframes 3 and 4 (e.g., only subframes 3 and 4 may be available). In particular, if the occupancy flag is not set, a lower priority WTRU may choose any SA resource for transmission.

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

[0160] A WTRU can be configured (e.g., by eNB and / or ProSe functionality) and / or preconfigured to send an occupancy flag that can be addressed to a low-priority user. For example, a WTRU can be configured to be used by "special users" (police chief, fire chief, etc.). A WTRU can (e.g., be enabled to) send an occupancy flag under certain conditions and / or triggers (e.g., an emergency situation). This trigger may enable the WTRU to do so over 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 SAs and / or a set of RRPTs that may be reserved for high-priority data. The WTRU may, for example, transmit those resources if the signal strength and / or signal occupancy falls below some predefined and / or known threshold (e.g., it may only transmit in such cases). Measurements may be taken at any point in time and / or scheduling period that the WTRU wishes to transmit, and / or they may include measurements taken in past scheduling periods and / or averaged over several past scheduling periods. Measurements may include measurements and / or RRSI, and / or similar occupancy or interference measurements. Thresholds may be statically defined and / or they may be configured in the WTRU via RRC signaling and / or via PHY layer signaling in a D2D synchronization channel (PD2DSCH).

[0162] For example, four SA subframes may be configured for D2D transmissions for every 80-millisecond scheduling period. The complete set of SA subframes 1-4 may be used by the WTRU for transmission and / or reception of high-priority D2D data. A subset of SA subframes 3-4 (e.g., only such a subset) may be used by the WTRU for low-priority D2D data. The WTRU can determine whether the D2D data it wishes to transmit is high-priority or low-priority. In particular, if the D2D data is low-priority, the WTRU can check the signal occupancy of SA subframes 1 and / or 2. Signal occupancy can be, for example, an average measurement of RSSI across the last N subframes. If the signal occupancy measurement of any of these subframes is below a threshold, the WTRU with the low-priority data to be transmitted can select that subframe for transmission. In particular, if the occupancy measurement is above a threshold, the WTRU with the low-priority data to be transmitted can use subframes 3 and / or 4 for transmission. In particular, WTRUs that can determine that they possess high-priority D2D data to be transmitted can transmit using SA subframes 1 and / or 2, and / or on any of the four SA subframes.

[0163] In some embodiments, different priority levels may exist, and correspondingly, different SA subframes and / or different thresholds may exist. A WTRU with the lowest priority level (e.g., of four levels) may check the occupancy measurement for one or more of the four subframes, or for each of them. In particular, in scenarios where the occupancy level of any of the four subframes falls below the corresponding threshold for that subframe, the WTRU may transmit on any of the subframes where the occupancy level was below the threshold. In particular, in scenarios where none of the SA subframes meet this criterion (e.g., at any given time), a WTRU with low-priority data to be transmitted may postpone its transmission to the next SA cycle and / or repeat the described technique.

[0164] In one or more techniques, one or more SAs and / or data resources, or sets thereof, may be reserved. A high-priority WTRU may transmit at higher power than a low-priority WTRU, particularly in scenarios where such resources are utilized. A WTRU with high-priority transmission may use these reserved resources (for example, may be restricted to use such resources). A WTRU with high-priority transmission may use one or more, or all, resources while respecting the transmit power value associated with the high-priority WTRU. A WTRU with low-priority transmission may use one or more, or all, resources (for example, reserved resources and / or unreserved resources) while respecting the transmit power value associated with the low-priority WTRU. One or more techniques that enable a low-priority WTRU to transmit at lower transmit power over 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 can be signaled by the network (e.g., via RRC signaling, NAS signaling, and / or MAC signaling), and / or statically determined, and / or defined. They can be defined / determined by ProSe functions. The presence of guaranteed isolated resources can, perhaps, be dynamically determined by one or more, or by each WTRU, based on one or more rules, and / or may not be identical for all WTRUs. For example, a low-priority WTRU can, perhaps, determine that an isolated resource may exist on a given scheduling period, based, perhaps, measurements taken on the current and / or previous scheduling periods, and / or current and / or past determinations of the presence of high-priority WTRUs. For example, a low-priority WTRU may, for instance, operate using the normal Release 12 rule on scheduling periods where such a decision could potentially indicate that there are no isolated resources at all, while still respecting the 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 non-SA D2D subframes, such as including D2D subframes and / or frequency domains permitted for D2D transmission. The features described herein may apply to more than two priority levels, e.g., low and high, e.g., low, medium and high, a range of priority, and other cases. The features described herein (e.g., stepped D2D transmission resources, which allow higher priority WTRUs to use time / frequency resources first, and allow lower priority WTRUs to select their own D2D transmission resources in time / frequency after determining (e.g., only after determining) which are being advertised as being used by higher priority WTRUs) may be applied to other D2D signals and / or non-SA channels.

[0167] D2D control and data access mechanisms may be provided.

[0168] D2D data transmissions carrying control signaling can be received and / or transmitted by WTRUs within a specified set of time / frequency resources.

[0169] D2D control signaling can refer to application layer control messages exchanged between D2D WTRUs to manage group calls, for example, for floor control, session control, connection establishment, and / or similar purposes. D2D control signaling can correspond to radio messages used to manage D2D connections and reception and / or transmission in WTRUs. Control signaling at the application layer can be a self-contained D2D PDU, or it can be multiplexed with D2D data such as carrying VoIP packets or segments thereof.

[0170] A specified set of time / frequency resources for sending and / or receiving D2D control messages may be obtained from one or more of the following parameters: timing values ​​such as frame counters or subframe counters, cell-wide frame values ​​or D2D system frame values, timing offset values ​​applied to reference subframes or reference frames, offsets applied to the generation of selected cell-wide signals or channels or D2D signals or D2D channels, frequency domain frequency indexes, RBs, or groups, cell-wide identifiers or D2D system identifiers or WTRU identifiers, group communication identifiers, or channel index values ​​or group index values.

[0171] Some or all parameters can be pre-configured in the WTRU, or they can be obtained through configuration signaling during system operation, or they can be derived by the WTRU using lookup tables, formulas, or equivalents. The WTRU can, for example, determine the D2D subframe, the allowed frequency domain, and other parameters, and then derive the D2D transmit resources as a limited and / or specified subset of the available transmit resources.

[0172] The WTRU can send or receive D2D control messages in a selected and / or reserved set of subframes that may contain a subset of possible D2D data subframes. When a 40-millisecond scheduling period is used, every fourth scheduling period may contain, for example, one, selected, or possible one or more, or each D2D communication group, a D2D control message or signaling.

[0173] A set of time / frequency transmission patterns may be used for sending and / or receiving D2D control messages. The set of transmission patterns can be predetermined and / or fixed, or it can 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) may be used for transmitting D2D control signaling associated with a D2D communication group. Using the features described herein, useful and / or time-critical D2D control signaling can take advantage of reserved D2D transmission resources in the system, for example, so that it is not interfered with or suffers from a lack of transmission opportunities when D2D data such as VoIP is transmitted simultaneously on the D2D transmission resources.

[0174] A D2D transmitter device is capable of transmitting D2D data. With respect to the examples described herein, a D2D transmitter device intended to transmit D2D data is capable of determining (e.g., first) the highest priority data available for transmission and the associated priority level of the D2D data. A WTRU is capable of determining the priority level of a WTRU (e.g., a high-priority WTRU). A D2D transmitter is capable of determining, for example, the corresponding SA and / or data radio resources to use for its D2D data transmission as a result of the priority determination. A D2D transmitter is capable of transmitting SA and / or D2D data over the determined radio resources. A WTRU is capable of determining the D2D resources it can use, for example, as a function of resources used by higher-priority users in the system. Transmission of SA and D2D data is capable of terminating, for example, if there is no more data to transmit. For example, if there is a possibility of changes to permitted radio resources with respect to high-priority or low-priority SAs, or if a new scheduling cycle can be initiated, or if a time-limited grant can expire, an appropriate reassessment and / or determination of radio resources may be made.

[0175] A D2D receiver device is capable of receiving D2D data. A D2D receiver device intended to decode D2D data is capable of determining SA and / or data radio resources. A D2D receiver device is capable of determining whether high-priority D2D transmissions or low-priority D2D transmissions can be received on the corresponding radio resources. A D2D receiver device is capable of attempting to decode one or more radio resources, or all radio resources and / or a selected subset of radio resources (e.g., only such subsets), determined as a function of parameters, such as D2D services that can be received. For example, if there is an ongoing high-priority D2D data transmission that will be received by the device, it may choose not to receive it on radio resources corresponding to lower-priority SAs and / or data pools, for example, if receiver processing constraints exist. For example, if a device may be configured to receive selected types of D2D signals / channels (e.g., only certain selected types), such as low-priority background service signaling, it may choose not to receive and / or process radio resources corresponding to high-priority SAs / data pools. A D2D receiver device is capable of demodulating and / or processing D2D data transmissions using determined radio resources.

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

[0177] Priority-based access for D2D communication can be achieved, for example, through the use of persistence parameters while determining time / frequency resources for D2D transmission.

[0178] Persistence parameters for use in preferred D2D access can be associated with radio resources for scheduling allocation (SA), D2D data, control signaling, or service signaling, such as for one or more D2D data signals / channels, or for 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 mechanisms, or resource allocation with D2D grants.

[0179] Figure 8 illustrates priority-based access for D2D data using persistence parameters (e.g., SA). In Figure 8, persistence parameters can be used to determine whether radio resources can be used by a D2D transmitter device that has D2D data to be transmitted, and, if so, to determine which SA resources can be used for priority-based D2D data at the beginning of the scheduling cycle.

[0180] A D2D transmitter intended to transmit D2D data is capable of determining the 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. With respect to SA resources deemed available, the D2D transmitter can subtract a random number between 0...1 for one or more (e.g., all) SA access opportunities. The D2D transmitter can compare whether the random number subtracted for a given SA access opportunity is higher than a threshold (e.g., PH=0.2) for high-priority data. If yes, it can choose to transmit any high-priority D2D data on the resource 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 (e.g., only if such a case exists), for example, if the random number subtracted 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 then repeat the above process for the next incoming SA resource pool.

[0181] A D2D transmitter may determine (e.g., on average) that a certain number (e.g., about 60%) of SA access opportunities are valid for the (e.g., exclusive) transmission of any high-priority data. A D2D transmitter may determine that a certain number (e.g., 20%) of SA access opportunities are valid for any low-priority and / or high-priority data. A D2D transmitter may consider a certain number (e.g., about 20%) of SA access opportunities to be prohibited.

[0182] The use of persistence parameters can statistically result in high-priority D2D data being transmitted by D2D terminals (e.g., considerably) more frequently than low-priority D2D data. Priority-based access for D2D communication can be improved by allowing higher-priority data (e.g., control signaling) and / or higher-priority users to acquire SA and / or data resource selection more frequently than lower-priority users.

[0183] Figure 8 can be extended to more than two priority classes having SAs or data pools. For example, persistence parameters associated with N=4 priority categories may be used. Access opportunities for D2D data transmission can be interpreted from a set of time / frequency resources that are determined and / or signaled and / or limited to different subframes and / or frequency domain ranges. A list of available resources may be obtained from prior measurements and / or channel observations. The examples described herein can be extended to persistence parameters associated with subframes representing time and / or counters and / or indices, 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, independently or in conjunction with one or more scheduling periods, to semi-persistent, time-limited, or dynamically permitted D2D data transmissions. While 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 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 can be achieved, for example, through the use of persistence parameters while determining effective time / frequency resources for D2D transmission.

[0186] A D2D transmitter device can determine whether a D2D transmission opportunity is permissible, for example, as a combination of channel measurements in conjunction with persistence parameters. Channel measurements may be replaced by (e.g., random) selection of candidate D2D transmission opportunities.

[0187] The persistence parameters for use in preferred D2D access may be publicly announced by the controlling device. The controlling device can be a D2D terminal. The controlling device can be an LTE radio network device such as a base station.

[0188] A controlling device can signal a set of persistence parameters (e.g., a first set of persistence parameters) associated with a radio resource that will be used for high-priority D2D data transmission. The controlling device can also signal a set of persistence parameters (e.g., a second set of persistence parameters) for a radio resource that will be used for lower-priority D2D data transmission. The persistence parameters can distinguish between different types of D2D data and / or control or service messages, and can include different sets of parameters for different types of signaling.

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

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

[0191] A transmitting D2D terminal can determine, for example, in the first instance, that any D2D access opportunity is unacceptable as a result of persistence checks. A transmitting D2D terminal can postpone its attempt to transmit D2D data to a later time (e.g., a second time). A D2D transmitter can reduce the threshold for low-priority access to a lower value (e.g., PL=0.7). This can be true, for example, if certain conditions are met (e.g., based on signal conditions, timing values ​​or counter values, signaling events, etc.). If, during a later time instance (e.g., a second time), it still fails to transmit its low-priority data, it can reduce the threshold to a lower value, for example, 0.6. If, in a later time instance (for example, a third instance), it succeeds in sending low-priority D2D data, the D2D terminal may reset the threshold to its initial value, e.g., PL=0.8, for any subsequent initial attempts to send low-priority data.

[0192] Persistence parameters may be adjusted by a D2D transmitter as a function of one or more (e.g., one) of the following events or observations, successful or failed access attempts, available absolute or relative D2D traffic volume in the queue, timer or counter values ​​at expiration (e.g., for latency-sensitive traffic or to satisfy latency requirements), or as a function of preceding D2D data transmission or reception events, signals received from other D2D terminals or LTE infrastructure nodes, or received signal strength of channels. Adjustments of persistence parameters by a D2D terminal can occur separately for different types of D2D data, such as a set of persistence parameters that are continuously monitored and / or updated regarding D2D control signaling (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), and 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 related to D2D discovery.

[0193] Persistence parameters applicable to the type of transmission for a D2D terminal can be adapted, for example, as a function of the characteristics of received D2D signals transmitted by other terminals. Such signals may or may not be directed to the D2D terminal to which the persistence parameters are adapted. The characteristics may include, in some cases, suitability relating to the number of D2D transmissions received over a period of time from a particular channel (e.g., PSCCH or PSSCH), or one or more priority levels associated with at least one received D2D transmission.

[0194] A WTRU may reduce the persistence parameters applicable to a transmission type if it has received at least one D2D transmission (or its associated SA). A received D2D transmission may have to satisfy at least one of the following conditions: the priority level of the received D2D transmission may be higher than or equal to the priority associated with the transmission type; the received D2D transmission may have to be received within 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; or the resource (e.g., resource pool) from which the D2D transmission was received may have to match one of the sets of resources, such as resource pools, associated with transmission types to which persistence parameters are applicable.

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

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

[0197] The WTRU can receive the value of the persistence parameter from the PSCCH or PSSCH field of the received D2D transmission, and if it is lower than the current value, it can apply this value until the timer that starts when this transmission is received expires.

[0198] The persistence parameter can be constrained to stay within a defined range, for example, so 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 parameters to be supported may be configured by a higher layer, predefined, or preconfigured. Such supported parameters may include, for example, one or more of the step size, interval, duration of the evaluation cycle, persistence values ​​(e.g., for one or more of the fields to be received, or each value, where applicable), the corresponding interval of the number of transmissions received within the evaluation cycle, or one or more of the minimum and maximum values.

[0200] The characteristics of the received D2D signals described herein can determine the selection of a resource pool from a set of candidate resources (for example, this may be in addition to the persistence parameter). For example, WTRU can select a resource pool that maximizes or minimizes a certain metric, which may be a function of the number of received D2D transmissions on the resource pool. The metric can be evaluated in the same way as the persistence value described herein (for example, it decreases as the number of received D2D transmissions in a time period increases).

[0201] The persistence parameters applicable to the transmission type for a D2D terminal can be tuned as a function of the characteristics of the received D2D signal transmitted by one or more other terminals. Such signals may or may not be directed to the D2D terminal to which the persistence parameters are adapted. The characteristics of the received D2D signal may include, depending on the circumstances, characteristics relating to the number of D2D transmissions received over a period of time from a particular channel (e.g., PSCCH or PSSCH), or one or more priority levels 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 the persistence parameters applicable to a transmission type if it has received at least one D2D transmission. A received D2D transmission may have to satisfy at least one of the following conditions: the priority level of the received D2D transmission is higher than or equal to the priority associated with the transmission type; the received D2D transmission is received within a certain duration after the last received D2D transmission (e.g., of the same or higher priority); the group destination ID, or source ID or destination ID associated with the received D2D transmission matches a certain value; or the resource (e.g., resource pool) from which the D2D transmission was received matches one of the sets of resources, such as resource pools, associated with transmission types to which persistence parameters are applicable.

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

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

[0205] When a D2D transmission is received, the persistence parameter may be reduced by a first step size (for example, this can occur once, multiple times, or each time a D2D transmission is received). The persistence parameter may be increased at regular intervals by a second step size (for example, usually smaller than the first step size) so that its value can be progressively restored to a higher level in the absence of received D2D transmissions.

[0206] WTRU can periodically determine the value of persistence parameters based on the number of D2D transmissions received over past evaluation cycles.

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

[0208] The persistence parameter can be constrained to a defined range. For example, even if one of the aforementioned conditions is met, the persistence parameter cannot decrease below a certain value (or increase above a certain value).

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

[0210] The characteristics of the received D2D signals described herein can determine the selection of a resource pool from a set of candidate resources (for example, this may be in addition to the persistence parameter). For example, WTRU can select a resource pool that maximizes (or minimizes) a certain metric, which may be a function of the number of received D2D transmissions on the resource pool. The metric can be adjusted as described herein with respect to persistence values ​​(for example, it decreases if the number of received D2D transmissions in a time period is higher).

[0211] Priority-based access may include persistent wireless resources.

[0212] Priority-based access for D2D communication can be achieved through persistent radio resource allocation to high-priority D2D channels, high-priority signals, or high-priority users.

[0213] Persistent radio resource allocation can mean the use of radio resource transmission opportunities that can be held by a D2D terminal over a predetermined and / or pre-configured duration, such as the duration of a high-priority D2D transmission and / or beyond a single scheduling cycle. Persistent radio resource allocation can be characterized by the ability of a D2D terminal to hold acquired radio resources over an extended period of time without re-selecting a D2D transmission opportunity, for example, if it decides to access a D2D radio resource via a channel selection mechanism that initiates its high-priority D2D channel and / or D2D signal transmission. The channel selection mechanism can mean, for example, a random selection of radio resources such as subframes and RB combinations. The channel selection mechanism can mean measurement-based radio resource selection, such as at least a set of interfering RBs in a subframe. Channel selection can mean resource allocation via another device such as an eNB.

[0214] A D2D terminal intended to transmit a high-priority D2D voice group channel may, for example, determine permitted D2D subframes from information pre-stored in the device. This pre-stored information may include a set of subframes (e.g., a first set of subframes) permitted for the transmission of a set of SAs and / or subframes (e.g., a second subframe) permitted for use in D2D data over a given transmission period. The D2D terminal may perform channel selection via measurements on the SA subframes to determine a suitable, at least uninterrupted, transmission opportunity for its SA. The device may select one or more (e.g., two) PRBs in the SA subframes for the transmission of its own SA. Channel selection via measurements determining at least uninterrupted resources may imply delaying transmission to a later point in time, for example, if the D2D terminal may not identify a suitable (e.g., uninterrupted) transmission opportunity. The D2D terminal may, for example, transmit D2D data associated with this SA over a corresponding scheduling period once it has begun transmitting an SA. The corresponding D2D data in a subframe, and the position of the RB contained within the subframe portion of the scheduling cycle, can be indicated via a Radio Resource Transmission Pattern (RRTP). The RRTP can be included in the SA as part of its payload, for example, or it can be given via the time / frequency position of the SA, or a combination thereof. A D2D terminal may be permitted, for example, after the scheduling cycle has ended, to re-execute channel selection on the SA and / or corresponding D2D data resources, while retaining the radio resources it has acquired (as opposed to relinquishing those resources, for example). A D2D terminal may be able to avoid channel selection and / or ensure that no ongoing high-priority D2D transmissions are interrupted. Priority-based access can be improved (e.g., statistically) to ensure that high-priority D2D channels do not compete for access to resources.High-priority D2D channels can compete for resources at the start of transmission. Longer (e.g., sufficiently long) high-priority D2D transmissions, such as in a sequence of several more scheduling cycles, can utilize guaranteed access to D2D radio resources after they have been acquired. High-priority D2D data transmissions can be improved, for example, by being able to avoid interruptions during ongoing transmissions for channel selection.

[0215] If a D2D terminal that has selected a D2D transmission opportunity in a time cycle (e.g., a first time cycle) may have high-priority D2D data to transmit, it is possible to retain the acquired radio resources in a time cycle (e.g., a second time cycle).

[0216] For example, a D2D terminal may choose to transmit an SA in RB3-RB4 of subframe 1 in SFN1. Transmitting the associated D2D data in selected subframes from SFN1-16 allows for the continued use of the same or similar SA transmission opportunities, such as in RB3-RB4 of SFN17, over the next scheduling cycle.

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

[0218] A D2D terminal that has selected a D2D transmission opportunity at time T1 can retain the selected D2D radio resources for a predetermined amount of time before re-selecting a D2D transmission opportunity.

[0219] For example, a D2D terminal that has chosen to transmit SA in RB3-RB4 of subframe 1 in SFN1 can retain radio resources for a duration of 3.2 seconds.

[0220] D2D service access classes may be described herein.

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

[0222] D2D access class information can accommodate any type of parameter used to support priority-based access for D2D data transmission. A D2D access class for a given terminal can accommodate the D2D and / or public safety services it is capable of supporting.

[0223] D2D terminals may support file uploads and / or file downloads (for example, they may support only those). D2D terminals may not support public safety voice call groups, for example, they may not support audio applications. D2D terminals may support exemplary D2D service access class 3 (for example, they may support only that) and may use any publicly announced low-priority D2D access opportunity (for example, they may use only that).

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

[0225] D2D terminals can support voice (e.g., voice only) and can be used by staff in the command structure or reserved for voice call groups. D2D terminals can support D2D service access class 1 (e.g., illustrative) for the highest emergency type voice calls and / or class 2 for high-priority D2D data access opportunities.

[0226] A D2D service access class can be associated with stored configuration information that enables the establishment of different types of permitted D2D services on a D2D terminal.

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

[0228] In a D2D terminal, the D2D service access class can be associated with a stored set of channel access parameters related to D2D preferred access.

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

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

[0231] A WTRU can transmit an indication that access to at least one resource is desired for the transmission of certain 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 the use of a preemption indication as described herein. A WTRU receiving 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., the application layer). This makes it possible to indicate to an end user that another user desires access to the resource.

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

[0233] An application may request a trigger transmission of a desired access indicator. Such a request may originate from an end user, for example, through a user interface. For example, one or more of the following may apply: The end user may press a specific key or button on equipment used for voice or data transmission, for example, in an emergency situation. The transmission of the desired access indicator may be triggered when a voice emotion recognition application detects an emotion that matches the emergency situation. The transmission of the desired access indicator may be triggered when a WTRU decides that one or more available resources (e.g., all available resources) are being used for transmissions from other WTRUs. The indicator may be triggered when detected transmissions from other WTRUs are at a lower priority level (e.g., only in such cases).

[0234] The transmission of a desired access indication may be triggered if a WTRU determines that it is possible that no other WTRU has transmitted a desired access indication that may still be valid (e.g., only in such cases). If a priority level is indicated as part of the desired access indication, such a condition may apply if an indication that may be transmitted by another WTRU indicates a priority (e.g., higher or equal priority) to the indication that would be triggered (e.g., only in such cases). Possible conditions for determining whether an received indication is valid may be described herein.

[0235] A desired access display may include one or more of the following: A WTRU may include one or more of the following (e.g., at least one) as part of the message containing the display: Identification information for the WTRU; A value that identifies the traffic that may be related by one or more displays ("Traffic Identification Information"); With respect to a transmitted display related to a given traffic (e.g., a first transmitted display), such value may be selected (e.g., randomly selected) from a subset of possible values ​​that may not be used by other displays; With respect to a display (e.g., a subsequent display), the value may be set to the same or similar value in other displays related to the same or similar related traffic (e.g., a previous display); One or more (e.g., at least one) characteristics of the traffic related by the display, such as priority level, duration, expected duration, data volume, data rate, transmit power level, application, service; One or more (e.g., at least one) identifiers of resources to which the display can be applied. A WTRU may be set to one or more (e.g., at least one) identifiers that identify the resources related by the display. The period of time (e.g., delay) before the relevant traffic can begin to be transmitted and / or before the display can be retransmitted. This value may correspond to the duration of a standby timer. For example, the indication at the expiration of the delay whether the relevant traffic can begin to be transmitted or whether the display can be retransmitted.

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

[0237] An action may be performed after the transmission of the desired action indication. After the transmission of the indication and / or after the transmission of the indication is completed, the WTRU may start a timer (e.g., referred herein as a “waiting timer”) whose duration corresponds to the time (e.g., the last) during which the WTRU can initiate the transmission of the involved traffic and / or retransmit the indication. The WTRU may monitor one or more (e.g., at least one) valid resources to detect whether they are 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 the transmission of traffic that may be involved by the desired access indication. The WTRU may consider a resource valid if it can be associated with a priority level equal to or lower than the priority level of the traffic being involved (e.g., only in such a case).

[0238] The WTRU can, for example, stop its waiting timer after detecting that one or more (e.g., at least one) resources may be available to send the traffic to be involved. The WTRU can then initiate the transmission of the traffic to be involved on one or more (e.g., at least one) resources.

[0239] After the standby timer expires, the WTRU may perform one or more of the following actions (e.g., at least one): The WTRU may resume sending indications and / or restart the standby timer. The WTRU may initiate sending related traffic on an active resource if it detects or does not detect transmissions from other WTRUs on that resource. After initiating the transmission of related traffic, the WTRU may start a timer (referred to herein as the “keep-alive” timer).

[0240] After selecting resources for sending the traffic to be involved, a WTRU may initiate the transmission of a selected resource representation, for example, to indicate to other WTRUs which resources have been selected. This may allow other WTRUs to resume transmission on resources not used by the WTRU. A selected resource representation may include one or more (e.g., at least one) resource identifiers (e.g., an index) and / or a duration or minimum duration for the use of the resource. A selected resource representation may be identical or similar to a desired resource representation, which may have signaled values ​​for resource identifiers that are different from the desired resource representation being sent (e.g., previously sent).

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

[0242] A release indicator may be transmitted. A release indicator transmission may be disclosed herein. A WTRU may trigger the transmission of a release indicator and / or stop the keep-alive timer if, for example, there is no longer any traffic related to a desired access indicator that may be transmitted (e.g., previously transmitted). Such a decision may be made using a mechanism similar to the one described herein, which may be used to trigger a desired access indicator based on a higher layer. The maximum duration for transmitting traffic related to a desired access indicator may be configured by a higher layer or otherwise. A release indicator may include traffic identification information corresponding to the traffic being related. A release indicator may be encoded and / or transmitted on the same physical channel as the desired access indicator.

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

[0244] Upon receiving a desired access indication, the WTRU may perform one or more of the following actions (e.g., at least one): The WTRU may consider the indication with respect to (e.g., only with respect to) traffic that has a priority lower than or equal to the priority level signaled by the received indication. This may be referred to herein as “unpreferred traffic.” The WTRU may stop any running wait timers and / or keep-alive timers associated with the received (e.g., previously received) indication that contain the same or similar traffic identification parameters. The WTRU may start or restart a wait timer for a duration in which the received indication may contain a value.

[0245] After receiving a selected resource indication, the WTRU can, for example, stop any running wait timers and / or keep-alive timers associated with the received indication (e.g., a previously received indication) that include identical or similar traffic identification parameters, and can start or restart keep-alive timers for a duration that may be included in the received indication. Indications can be transmitted to higher layers, such as the application layer or user interface, to notify the end user, for example, that another user may be attempting to access the resource. Such notifications can be visual (e.g., a light indicator), audible, or tactile (e.g., vibration).

[0246] A WTRU can determine whether it is sending (e.g., currently sending) non-priority traffic on one or more (e.g., at least one) resources related to the display. The set of resources related to the display can correspond to one or more (e.g., at least one) values ​​included in the display, if any. The set of resources can correspond to resources associated with priority levels that are equal to or lower than the priority levels included in the display. A WTRU can stop sending (e.g., stop immediately) non-priority traffic on such resources. A WTRU can stop sending, for example, at the start of the next scheduling cycle and / or when the standby timer expires. Interruptions to traffic sending on a resource may occur if another resource is available (e.g., only if such a resource is available) or if the display may not be sent to the application layer or user interface.

[0247] While a wait timer or keep-alive timer associated with a received (e.g., previously received) display may be running, or after receiving a selected resource display, the WTRU may select one or more resources (e.g., at least one) that are not part of the set of resources involved by the display in order to send and / or initiate the sending of non-preferred traffic.

[0248] Actions may be taken after receiving a release indicator and / or after the keep-alive timer expires. After receiving a release indicator, the WTRU may, for example, stop any timers (e.g., a standby timer or a keep-alive timer) associated with the received (e.g., a previously received) indicator that contain the same or similar traffic identification parameters. The WTRU may, for example, determine that no traffic may be disqualified with respect to the traffic identification information that may be included in the release indicator. After the keep-alive timer expires, the WTRU may, for example, determine that no traffic may be disqualified with respect to the traffic identification information that may be included in the associated release indicator (e.g., after which the timer may be started).

[0249] Preemption allows for the use of D2D-prioritized channel access.

[0250] Preemption indications can be explicit. Explicit preemption indications and the physical handling of preemption indications can be described herein. In a distributed scheduling D2D system, there may be no controlling entity to ensure that high-priority messages gain access to resources in a timely manner. Preemption can be a mechanism used by a device to interrupt (e.g., temporarily interrupt) an ongoing communication from another device so that the resource may be freed for its own use.

[0251] Preemption can be motivated when resources can be constrained and / or one or more resources, or each resource, can be utilized (e.g., currently utilized), such as when a WTRU transmits a high-priority message. Preemption may be used when resources can be occupied for a group of users (e.g., or other classifications) and / or when a higher-priority signal can be transmitted for that group (e.g., other radio resources are available and can 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 carry a certain amount of information. The indication may consist of a signal from which, for example, the amount of information (e.g., a limited amount) can be inferred.

[0253] Message-based representations may be described herein. A D2D WTRU may be configured to transmit a message-based preemption representation. A preemption message may carry one or more of the following information in any order or combination: resource index, identification information, priority level, amount of time to back off, interrupt cause, and / or T-RPT. A WTRU to preempt may indicate a specific resource index that can be selected from a list of resources being used (e.g., currently being used). Transmissions associated with that resource may be interrupted regardless of the identification information of the user transmitting on the resource (e.g., currently transmitting). Identification information may be used to indicate the target WTRU identification information and / or group identification information (e.g., which user / target group is allowed to stop transmitting) that will be preempted. Priority levels may be associated with the preemption message and / or with data transmissions. A WTRU may indicate the priority level associated with its transmission so that, for example, WTRUs with lower priority can stop transmitting. The amount of preempted WTRU time can interrupt its transmission. After the backoff time expires, the preempted WTRU may be allowed to resume transmission. The interrupt cause can be the cause of preemption. For example, the cause may be selected from a finite list including, for example, an emergency call, relaying, and others. T-RPT can be a pattern index to preempt. The WTRU can indicate (e.g., explicitly) the resources it may wish to interrupt.

[0254] A WTRU may be configured to send preemption messages via a scheduling assignment (SA). The WTRU may be configured to use a special identifier in the SA to indicate that the SA can be associated with a preemption message. The WTRU can send preemption messages via the SA, for example, as a control signal.

[0255] Preemption messages can be carried directly in SAs and consequently replace existing fields in SAs. WTRUs can use a reserved SA pool to send preemption messages using the SA format. D2D WTRUs sending data may be configured to monitor the preemption resource pool to determine whether their transmissions can be preempted. WTRUs receiving preemption messages may be configured to determine (e.g., blindly) whether the received SA can be a conventional SA or a preemption message. WTRUs can make this determination, for example, based on the CRC appended to the SA and / or preemption message (e.g., blindly). The preemption message portion may be carried in the data associated with the SA. For example, a preemption message may be carried via a MAC control element (CE).

[0256] WTRU can be configured to send preemption messages on the PUCCH resource.

[0257] This PUCCH resource can be associated with a D2D transmission. The association may be based, for example, on the characteristics of the SA associated with the transmission that the WTRU may wish to interrupt. For example, the WTRU may be configured to transmit a preemption indication at a known time at a specific PUCCH position in a frequency, after the SA has been transmitted and / or, for example, based on the SA resources that may be used.

[0258] WTRUs can transmit preemption messages using a signal format. WTRUs can be configured to transmit preemption messages within the time / frequency resources available for preemption.

[0259] A WTRU may be configured to send and / or receive preemption messages in (for example, only in) a specified set of time / frequency resources.

[0260] A specified set of time / frequency resources for sending and / or receiving preemption messages may be obtained from one or more of the following: timing values ​​such as frame counters or subframe counters, cell-wide frame values ​​or D2D system frame values, timing offset values ​​applied to reference subframes or reference frames, offsets applied to the occurrence of selected cell-wide signals or channels or D2D signals or D2D channels, frequency domain frequency indexes, RBs, or groups, cell-wide identifiers or D2D system identifiers or WTRU identifiers, group communication identifiers, or channel index values ​​or group index values.

[0261] Some or all parameters can be pre-configured in the WTRU, or they can be obtained through configuration signaling during system operation, or they can be derived by the WTRU using lookup tables, formulas, or equivalents.

[0262] A WTRU can send or receive preemption messages in a selected and / or reserved set of subframes that may contain a subset of possible SA subframes. For example, if an SA is configured over an 80-millisecond scheduling period, every fourth occurrence of an SA subframe for a given scheduling period may contain a preemption message. In this case of a shared resource where both SAs and preemption messages may exist, the WTRU can distinguish whether a particular time / frequency resource contains an SA or a preemption message by decoding it.

[0263] A WTRU can consist of a set of D2D subframes that are not used for SA or D2D data and can be used to send and / or receive preemption messages. For example, if an SA is configured over a scheduling period of 40 milliseconds, preemption messages can be sent or received in designated D2D subframes that are reserved for this purpose every 80 milliseconds and can not be used otherwise, for example, for SA or data transmission. In this case where dedicated time / frequency resources are used for preemption messages, the WTRU can detect a single transmission format (for example, only it is necessary to detect a single transmission format).

[0264] A WTRU can send and / or receive preemption messages in a subset of D2D data frames. While the SA announces D2D data over a scheduling period, a set of D2D data subframes may include control signaling that carries preemption messages. The WTRU can determine the presence and / or absence of preemption messages on a set of D2D subframes by decoding a selected signaling format.

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

[0266] Signal-based displays can be described herein.

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

[0268] While a preemption signal itself may not carry any information (e.g., explicit information), indications (e.g., implicit indications) can be inferred from the signal reception by the receiving WTRU.

[0269] A receiving WTRU can determine information from the preemption signal based, for example, on the signal, time / frequency transmission, and / or other indices. The preemption signal may be transmitted over a set of PRBs that can be associated with an ongoing transmission that will be preempted using a known set of rules. A WTRU may be configured to transmit the preemption signal over a set of PRBs associated with SAs associated with transmissions it may wish to preempt.

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

[0271] The WTRU can base its selection of the preemption signal on one or more of the elements described herein.

[0272] It can be determined when a preemption indicator will be sent. The WTRU can be configured to determine the conditions under which a preemption indicator will be sent. The WTRU can be configured to decide to send a preemption indicator based on one or more of the following triggers (in any order or combination): The WTRU can have data to send. The WTRU can be configured and / or allowed to use preemption. The data to be sent may be associated with a logical channel / bearer / QoS / QCI where preemption is allowed and / or can be configured. The WTRU can receive commands to start / stop preemption from a higher layer (e.g., RRC). The data packets to be sent may be associated with a request for preemption sent by a higher layer (e.g., MAC). The WTRU can determine, for example, based on SA measurements or monitoring, that there may not be any available radio resources to send its data. A WTRU can determine that there is one or more (e.g., at least one) resources available for use and / or that can be preempted. A WTRU may be configured to determine the priority level of one or more, or each data transmission, based on the SAs it can receive. A WTRU may be configured to determine, with respect to one or more, or each received SA, and / or with respect to one or more, or each received transmission, whether it can be preempted. This can be done based on one or more of the following: absolute priority, source identification information, target identification information for transmission, and others. For example, the priority of data to be transmitted may be higher than that of one or more (e.g., at least one) ongoing transmissions. The priority of a WTRU may be higher than that of one or more (e.g., at least one) other WTRUs transmitting data.A target group's priority can be higher than the priority of one or more other target groups (e.g., at least one) from which data may be transmitted.

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

[0274] The WTRU can determine whether or not to operate based on the received preemption signal.

[0275] If a WTRU can determine that it has received a preemption indication, it can be configured to determine whether it is able to and / or may desire to act in accordance with the preemption indication. The WTRU can be configured to determine whether it is able to and / or may desire to act in accordance with the received preemption indication based, for example, on one or more of the following: a priority level that can 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 for the target group, etc.); or a target WTRU that can be associated with the preemption indication. For example, a preemption indication can carry information indicating a target transmitter / transmit from which an interrupt will occur. The WTRU may be configured to determine whether it is the target of a preemption indication, for example, based on the content of the preemption message (e.g., transmitter identifier, group identifier, specific resource identifier, priority level, etc.) or (e.g., implicitly) based on the time / frequency / signal characteristics of the preemption signal.

[0276] Preemption applications may be described herein.

[0277] A WTRU can be configured to act in accordance with preemption indicators received by the WTRU and to release resources that may be preempted. After detecting a preemption indicator in which it can and / or may desire to act, the WTRU may be configured to do, for example: The WTRU can stop data transmission. The WTRU can release resources. The WTRU may be configured to stop transmission of the SA. The WTRU may be configured to send an indicator of resource release. For example, the WTRU may be configured to send a special indicator of termination in the SA that indicates the cause of the termination of transmission (e.g., preemption) (e.g., optionally indicated). The WTRU may be configured to start a backoff timer (e.g., of a predefined value). The WTRU may be configured not to resume data transmission and / or attempt to transmit data until the timer expires. Once preemption is complete and / or after the preemption timer has expired, the WTRU may be configured to reinitialize the transmit as if it were a new (e.g., fresh or updated) transmit (e.g., by re-evaluating the transmit parameters).

[0278] A WTRU may be configured to “hold” a resource for the duration of the preemption interrupt. A WTRU may be configured to send an indication that it is holding a resource. For example, a WTRU may be configured to send an indication in the SA that a resource is being held (e.g., “channel held”), indicating the cause of the resource being held (e.g., preemption) (e.g., indicated as optional). A WTRU may be configured to start a backoff timer (e.g., of a predefined value). A WTRU may not be allowed to resume data transmission and / or attempt to transmit data until the timer expires. After preemption is complete and / or the preemption timer has expired, a WTRU may be configured to resume transmission using the same resource that was preempted. A WTRU may be configured (e.g., optional) to resume transmission using the same or similar resource (e.g., only resume) if it resumes transmission within the same or similar scheduling period. A WTRU may be configured to indicate to a higher layer the reception of a preemption indication that it is therefore capable of and / or may desire to operate. For example, a WTRU may be configured to indicate to a higher layer when a channel may be busy and / or when the WTRU may be holding off on transmission. A WTRU may be configured to indicate to a higher layer 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 elapsed. A WTRU may indicate to a higher layer when the duration of an interrupt due to preemption may be longer than a certain predefined duration.

[0279] D2D terminals can be used to perform preferred channel access.

[0280] Transmit and / or receive half-duplex may be the priority-based access used. A D2D terminal can handle multiple D2D channels / signals that will be transmitted and / or received based on the priority of the D2D channels and / or D2D signals.

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

[0282] Figure 9 is an illustrative diagram of preferred reception of a high-priority channel by a D2D terminal with FDD half-duplex operation. In Figure 9, the D2D terminal can have (for example, simultaneously) a high-priority D2D voice channel (e.g., a first high-priority D2D voice channel) that it will receive, such as for voice group calls, and a lower-priority D2D data channel (e.g., a second lower-priority D2D data channel) that it will transmit, such as for file uploads.

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

[0284] After receiving a transmission request for a low-priority D2D data channel (e.g., the second low-priority D2D data channel) at time point T1, the D2D terminal can adjust its transmission scheduling to enable complete reception of one or more, or all, subframes corresponding to the high-priority D2D channel. The D2D terminal can, for example, choose not to use some subframes that were initially scheduled for transmission of the low-priority D2D channel and use the indicated subframes for reception of the high-priority D2D data channel if a collision occurs. At time point T2 when the talk spurt of the incoming high-priority D2D voice channel ends and the 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 complete transmission of the low-priority D2D data channel (e.g., the second low-priority D2D data channel). While prioritizing reception of the high-priority D2D channel during the time period T1 to T2, the D2D terminal can choose to indicate a radio resource transmission pattern (RRPT) that can be selected as a function of D2D subframes determined to be available for transmission, for example, after considering those for reception. The D2D terminal can choose to indicate an RRPT that includes D2D subframes for its own transmission and / or for which it can receive high-priority D2D data. The D2D terminal can choose not to transmit in these.

[0285] The D2D terminal can process (e.g., automatically process) one or more, or a plurality of D2D channels and / or D2D signals to be transmitted and / or received based on the priority processing associated with such a plurality of D2D channels and / or D2D signals. User intervention such as manual channel switching or deferral of transmission can be made unavailable. Signal reception regarding high-priority D2D channels can be received by dedicating reception capabilities (e.g., full reception capabilities) to the D2D subframes carrying the high-priority D2D channels and / or D2D signals.

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

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

[0288] The D2D data received (for example, simultaneously received) can be voice packets, control packets, service packets, and / or data packets, such as IP packets corresponding to file downloads. The Tx / Rx processing and / or prioritization of multiple channels and / or signals to be received or transmitted may similarly apply to channels and / or signals received or transmitted over cellular communications and D2D radio links.

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

[0290] A D2D terminal can determine a transmit and / or receive schedule that ensures an appropriate number of D2D subframes are used for transmitting or receiving high-priority D2D channels and / or D2D signals. A D2D terminal can determine appropriate D2D subframes based on various criteria, such as the minimum set and / or identified set of SA resources that can receive or transmit SA, the required number and / or sets of D2D subframes corresponding to possible D2D data reception or transmission, the number of sets of subframes unavailable for use in ongoing cellular communications for D2D transmission and / or reception, and / or one or more of the number and / or sets of D2D subframes corresponding to transmission and / or reception from / to one or more WTRUs and / or D2D communication groups.

[0291] A D2D terminal can decide to skip a transmit or receive opportunity initially planned for a lower-priority D2D channel and / or D2D signal. The D2D terminal can select available transmit / receive opportunities for lower-priority D2D channels and / or D2D signals by determining which transmit / receive opportunities may be used for higher-priority D2D channels and / or D2D signals. The WTRU can continue transmitting or receiving lower-priority D2D channels or D2D signals, but can skip transmits or receive in subframes that overlap with subframes where higher-priority D2D channels or D2D signals are being transmitted or received.

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

[0293] A D2D terminal can process multiple D2D channels and / or D2D signals that are to be transmitted or received, for example, based on the priority associated with these D2D channels or D2D signals. Processing may include selecting the transmission and / or reception opportunities for a D2D channel and / or D2D signal (e.g., a first D2D channel and / or D2D signal) as a function of what is useful for the D2D channel and / or D2D signal (e.g., a second D2D channel and / or D2D signal).

[0294] A device that processes multiple D2D data channels can be described herein.

[0295] A D2D terminal can process multiple received (e.g., simultaneously received) D2D channels or D2D signals based on the priority of the received D2D channels and / or D2D signals.

[0296] A receiving D2D terminal can receive multiple incoming (e.g., simultaneously) D2D channels or D2D signals. Based on the priority of the received D2D channels or D2D signals, it can store in memory (e.g., temporarily store) demodulated or decodeable bitstreams or decoded information content that can correspond to the received channel samples, lower-priority D2D channels and / or D2D signals, while processing and / or transferring and / or presenting them to a user or device output.

[0297] Figure 10 is an illustrative diagram of multiple D2D channels (e.g., voice) being received simultaneously. In Figure 10, a D2D terminal can simultaneously receive D2D voice channels (e.g., a first high-priority D2D voice channel) for emergency first responder direct voice lines and / or D2D voice channels (e.g., a second lower-priority D2D voice channel) for push-to-talk group calls.

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

[0299] In some scenarios, particularly after the start of receiving a low-priority D2D voice call at time T1 (e.g., the second low-priority D2D voice call in Figure 10), the D2D terminal may continue demodulating, decoding, and / or forwarding any D2D data acquired from a high-priority voice channel (e.g., the first high-priority voice channel in Figure 10) to the device's audio output path, while it may also store (e.g., temporarily store) the decoded samples or signal representations of any lower-priority D2D voice calls received (e.g., the second lower-priority D2D voice call in Figure 10) in memory. At time T2, if the talk spurt of a high-priority D2D audio channel (e.g., the first high-priority audio channel in Figure 10) has ended and a low-priority D2D audio channel (e.g., only the low-priority D2D audio channel in Figure 10) is available, the D2D terminal can switch its audio path from the high-priority D2D audio channel to the low-priority D2D audio channel. Transferring such stored channel samples and / or decoded information content corresponding to the low-priority D2D audio channel from memory (e.g., temporary memory) to the audio path may involve a time delay or delay. For example, in Figure 10, 24 audio frames in 3 scheduling cycles, or approximately 480 milliseconds, or each 20-millisecond codec interval, are processed and played back from temporary memory. One or more (e.g., many) D2D applications may support push-to-talk type audio rather than two-way conversational audio. Such a time delay or delay introduced through storing (e.g., temporarily storing) the low-priority D2D audio channel may be acceptable.

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

[0301] A WTRU can be configured, or pre-configured, with rules to determine whether data of different priorities can be multiplexed together in a PDU, or whether they may be required to be transmitted on different transmission occasions. For example, a network can allow a WTRU to multiplex data belonging to a second and 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 on the same TB.

[0302] The examples described herein, and Figure 10, can be extended to more than two priority classifications. Different scheduling period lengths can be used. SA transmissions can correspond to D2D data transmitted in later scheduling periods and / or multiple scheduling periods. Independent of or in conjunction with scheduling periods, principles of semi-persistent, time-limited, and / or dynamically permitted D2D data transmission can be used. Time resources and / or frequency resources can not be contiguous. The examples used scheduling assignments, as well as high-priority and low-priority received D2D voice channels, for illustrative purposes, but the principle of temporarily buffering and storing samples corresponding to low-priority D2D channels and / or D2D signals can be similarly applied to different D2D channels and / or signal message types. For example, D2D discovery messages can be stored (e.g., temporarily) for processing at a later point in time, while high-priority D2D control or data signaling can 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 IP packets corresponding to file downloads. The use of buffering and / or storing (e.g., temporarily buffering and / or storing) samples corresponding to received D2D channels (e.g., a second received D2D channel) in memory may be applied to avoid receiver limitations in a D2D terminal relating to, for example, device architecture, component availability for real-time processing, device output representation of received D2D data, and / or requested user interaction, etc. Receiver processing and / or prioritization of multiple received (e.g., simultaneously received) channels and signals may similarly apply to channels or signals received from cellular communications and D2D radio links.

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

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

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

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

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

[0309] In one or more techniques, a relay node may request and / or create one or more separate radio bearers for each level of priority of data it can receive from any of the remote WTRUs to which it is currently capable of providing service. The relay WTRU may, among other things in a scenario, utilize one or more existing radio bearers that may be associated with (e.g., various) degrees of quality of service (QoS) to serve one or more different priority transmissions made by the remote WTRU toward the relay (e.g., higher priority transmissions mapped to one or more bearers with better QoS, or similar).

[0310] A relay WTRU can set up one or more, or one or more, or a set of radio bearers for each of N priority levels it is capable of providing service to, and / or the WTRU can select one or more existing radio bearers that can be used for the data associated with each priority level. For example, in a scenario in particular where a relay WTRU receives data from a D2D link, it can determine the priority of packets received from a remote WTRU. This determination can be made, for example, at the MAC layer, IP layer, and / or application layer, among other layers. For example, if the determination is made at the MAC layer, the priority level of the received MAC PDU can be determined by one or more of the following: The MAC PDU transmitter should include a priority level in the MAC header. In such a scenario, in particular, the receiving MAC entity can determine its 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. A logical channel ID value can be associated with a specific priority. For example, LCIDs 1-8 can be used for D2D communication, and priority levels can be associated with selected IDs (e.g., in increasing / decreasing priority order).

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

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

[0313] For example, based on the priority of the data to be received, a relay WTRU may be able to determine which radio bearer (e.g., one with an associated QoS level) to use for transmitting the received data. A 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. A WTRU may consist of (e.g., dynamically) a mapping of priority levels to radio bearers by an eNB and / or use this mapping to transmit one or more IP packets on one or more existing radio bearers.

[0314] In some techniques, one or more wireless bearers having the same or similar QoS characteristics may be used to transmit data received from a remote WTRU by a relay WTRU to the eNB / network. The relay WTRU may, for example, buffer lower priority data over a period of time while (e.g., selectively) forwarding higher priority data to one or more higher layers. The relay WTRU may, in particular in scenarios, be able to handle higher priority data (e.g., forwarded to higher layers) and / or, may be able to handle lower priority data if lower priority data is forwarded to higher layers (e.g., only in such cases).

[0315] For example, a relay WTRU may consist of a timer that can buffer lower-priority data while forwarding higher-priority data. The timer may be reset once 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. In some scenarios, in particular, after the timer has expired (for example, indicating that no higher-priority data has been received over a period of time) (for example, only after such a period), the WTRU may forward the buffered lower-priority data to one or more higher layers.

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

[0317] In some techniques, WTRUs can transfer data to a higher layer (e.g., selectively) with a certain probability. A higher probability of transfer can be associated with higher-priority data / channels, and / or a lower probability of transfer can be associated with lower-priority data / channels. The higher layer may, for example, process the data in the order it was received.

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

[0319] Although several techniques may be described herein using two priority levels, any of the techniques intended can be extended to multiple (N) priorities by those skilled in the art.

[0320] A transmission that processes multiple D2D data channels in a device may be described herein. A D2D terminal can process multiple D2D channels or D2D signals (e.g., simultaneous D2D channels or D2D signals) to be transmitted based on the priority of the D2D channels or D2D signals.

[0321] A D2D terminal may wish to transmit and / or transmit multiple D2D channels or D2D signals (for example, simultaneously). Based on the priority of the D2D channels or D2D signals to be transmitted, it may, for example, store in memory (for example, temporarily store) information content or encoded bitstream or samples corresponding to lower-priority D2D channels and / or D2D signals to be transmitted, while processing and / or transferring another higher-priority D2D channel and / or D2D signal and presenting it to the transmission path.

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

[0323] Figure 11 is an illustrative diagram of multiple simultaneous D2D channels (e.g., voice and data) that will be transmitted. In Figure 11, a D2D terminal can transmit (e.g., simultaneously) higher priority D2D voice channels (e.g., a first high priority D2D voice channel) and / or lower priority D2D channels (e.g., a second lower priority D2D channel), such as a voice call group channel.

[0324] In Figure 11, talk spurts corresponding to high-priority D2D voice channels (e.g., a first high-priority D2D voice channel) may be processed by a D2D terminal over multiple scheduling cycles, for example, up to time T2. Device internal requests to transmit low-priority D2D data channels (e.g., a second low-priority D2D data channel) may be received, for example, starting from time T1. Requests may be issued by a user or by an application capable of processing data packets for D2D and / or issuing such requests. A D2D terminal may have a transmit (e.g., single transmit) front-end chain. In any given subframe, one or more (e.g., only one) transport blocks (TBs) of a D2D channel may be presented to the Tx path, for example, to use its (e.g., full) available output power on that subframe with respect to the D2D channel under consideration. This makes it possible to maximize the feasible link budget for the D2D channel. A D2D terminal may transmit high-priority and / or low-priority D2D channels and / or their control signaling (e.g., simultaneous control signaling) in different subframes.

[0325] After receiving a transmit 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 transfer any D2D data that may be available to a high-priority voice channel (e.g., a first high-priority voice channel) to its transmit path, while it may store (e.g., temporarily store) and / or buffer any samples or signal representations of a lower-priority D2D data channel (e.g., a second lower-priority D2D data channel) that will be transmitted (e.g., simultaneously transmitted). At time T2, if the talk spurt of the high-priority D2D voice channel (e.g., a first high-priority D2D voice channel) has ended and a low-priority D2D data channel (e.g., only a low-priority D2D data channel) is available for transmission, the D2D terminal may switch its transmit path from the high-priority D2D voice channel to the low-priority D2D data channel. Transferring such stored samples and / or informational content corresponding to low-priority D2D data channels from memory (e.g., temporary memory) to the transmit path may involve a time delay or lag. For example, in Figure 11, approximately 3 scheduling cycles, or approximately 480 milliseconds, may be required for processing from temporary memory. If the D2D application can handle data types that are not time-critical, such as two-way conversational voice, then the time delay or lag introduced through storing (e.g., temporarily storing) part or all of the low-priority D2D data transmission may be acceptable.

[0326] In Figure 11, the D2D terminal can intermittently multiplex lower-priority D2D data transmissions while, for example, a higher-priority D2D voice channel transmission is in progress. This is possible in D2D subframes that do not need to be used for the transmission of transport blocks for the higher-priority D2D voice channel (for example, only in the D2D subframes in Figure 11). By time T2, lower-priority D2D data that is ready for transmission and can be received by the transmission path between time T1 and T2 for the lower-priority channel may have been transmitted between T1 and T2.

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

[0328] The examples described herein and shown in Figure 11 can be extended to cases of more than two priority classes. Different scheduling period lengths can be used. SA transmissions can correspond to D2D data transmitted in later scheduling periods or in multiple scheduling periods. Principles of semi-persistent, time-limited, and / or dynamically permitted D2D data transmission can be used, independently of or in conjunction with scheduling periods. Time resources and / or frequency resources can not be contiguous. The examples may use scheduling assignments for illustrative purposes, as well as high-priority 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 can similarly be applied to different D2D channels and / or signal message types. For example, a D2D discovery message to be transmitted can be stored (e.g., temporarily stored) and / or queued for processing at a later point in time, while high-priority D2D control or data signaling can be processed after the D2D terminal receives the request to transmit.

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

[0330] A D2D terminal can determine whether it can receive a request to transmit a D2D channel and / or D2D signal (e.g., a second one) 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 can determine which of the D2D channels or D2D signals to be transmitted (e.g., simultaneous D2D channels or D2D signals) can be processed directly and which can be stored in memory (e.g., temporarily stored). The decision may be based on the priority associated with the D2D channels or D2D signals or communications to be transmitted. Directly processing a sample or information representing a D2D channel and / or D2D signal to be transmitted can imply presenting the information to the terminal's transmission path, or it can imply forwarding such a sample to other processing components running on the D2D terminal. Storing in memory (e.g., temporarily) can 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] A D2D terminal can determine when to process D2D data stored (temporarily stored) in memory. A D2D terminal can decide to apply direct processing to such stored (e.g., temporarily stored) samples or informational content of D2D channels and / or D2D signals to be transmitted, for example, as described herein. A D2D terminal can transfer stored samples to an output component of the device, such as a transmitter path. It can determine, for example, that stored samples may be discarded if a selected set of time delays and / or conditions are met. The device can, for example, transmit a higher-priority D2D channel as part of a transmitted (e.g., simultaneously transmitted) portion of a lower-priority D2D channel and / or D2D signal (e.g., a second lower-priority D2D channel and / or D2D signal) during a time period in which it is possible to transmit a higher-priority D2D channel, such as in a subframe in which it is possible that it is not in use by a higher-priority D2D channel and / or D2D signal.

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

[0333] A D2D terminal can process multiple D2D channels or D2D signals to be transmitted based on the priority of the simultaneously transmitted D2D channels or D2D signals. Processing may include, for example, transmitting, and / or discarding, and / or prioritizing, a portion or all of a D2D channel and / or D2D signal to be transmitted in the presence of other D2D channels or D2D signals to be transmitted by the device.

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

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

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

[0337] A WTRU can consist of several separate priority access groups, allowing it to run multiple services or applications. The WTRU can determine how to map the D2D data it will send to the available priority access groups.

[0338] Priority access groups may refer herein to any scheme or resource pool configuration described herein that supports data priority and / or traffic differentiation (e.g., different resource pools with different priorities, priority access within the same resource pool, etc.).

[0339] A WTRU can determine which priority access group to use based on one or more of the following parameters, or a combination thereof, as described herein. A WTRU can use a configured mapping between ProSe bearers and / or ProSe / application layer packets and / or priority access group logical channel priorities or LCG priorities. 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 services, or each service, associated with a particular group, traffic type, and / or user type may have priorities assigned by higher layers. When a packet arrives at the access layer, it may be mapped to a logical channel or PDCP entity based on the group destination, source destination, and / or associated priority. With respect to a given logical channel, a WTRU may be aware of the packet's priority, and based on the mapping, a WTRU can determine which priority access group the packet or logical channel belongs to. A WTRU can 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 consist of one or more sets of TFT filters for each traffic type, and one or more priorities for logical channels or access groups associated with each traffic type. For example, a WTRU may consist of (e.g., three) TFT filters and mapping rules for one or more of them, or each of them (e.g., voice traffic is mapped to priority access group 1, video traffic to priority access group 2, and data traffic to priority access group 3).The WTRU can perform traffic inspections to determine the traffic class of one or more packets, or each packet, and / or it can look up configured mapping rules to determine, for example, which priority access group may be used.

[0340] A WTRU, possibly acting as a repeater and / or receiving data (for example, first) on a cellular / Uu link, can determine which priority access group to use based on the mapping of EPS bearers and / or radio bearers capable of receiving data to priority access groups on a D2D link. For example, a WTRU acting as a repeater may consist of separate EPS / radio bearers transmitting data for different priority levels. A WTRU can map data received on a particular EPS bearer to a specific priority access group, possibly based on a predefined and / or signaled mapping (for example, by an eNB or ProSe function).

[0341] A WTRU can determine priority access groups on a per-device basis based on its device configuration (for example, one, more, or all services from that device may use, or always use, the same or similar priority access). A WTRU can be configured with device / WTRU priorities based on, for example, a hierarchy within a group (for example, the fire chief may be configured to have the highest priority in the group). A WTRU can determine priority access groups based on observed traffic characteristics within the WTRU. A WTRU can retain historical and / or ongoing traffic characteristics (e.g., inter-incoming time, data rate, etc.) and / or determine appropriate priority access groups that can be used to satisfy those traffic characteristics. A WTRU can determine priority access groups based on a function of the D2D WTRU. For example, if a WTRU can operate as a relay, some or all of the traffic may be mapped to a certain priority access group, or the WTRU may be configured to use a different (higher) priority access group when operating as a relay. A WTRU can determine priority access groups as a function of services configured by higher layers. For example, if a higher tier requests a D2D request for emergency services, the WTRU can determine the usefulness of using an emergency priority access group.

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

[0343] A WTRU within a coverage can be configured to report to the ProSe function / eNB any priority access groups that the WTRU may be using. The eNB may be provided with the configuration parameters described herein (e.g., LCG ID mapping, logical channel, priority level, and / or priority access group) from the ProSe function and / or from another node in the network (e.g., MME), for example, in scenarios in which the mapping may not be determined by the WTRU (e.g., alone).

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

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

[0346] A WTRU can determine how to multiplex and where to send some or all of the data using one or more (e.g., only one) determined priority access groups. For example, a WTRU can decide to send all D2Ds 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 tier, some or all of the traffic from that device may be sent using the emergency priority access group). For example, a WTRU can determine the highest priority service or priority access group to which data is available and the resources or transmission characteristics to which this priority service may be sent. A WTRU may enable multiplexing of priority services together (e.g., any of the priority services together) and sending them using the transmission characteristics of the highest priority data. Logical channel prioritization may be implemented in the transmitter to prioritize lower traffic classes to higher traffic classes, for example, for one or more PDU creations or for each PDU creation. In cases where a WTRU is limited to multiplexing data from a single 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 multiplex data from different priorities belonging to that destination within the same PDU, for example, using LCP and available space.

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

[0348] Data may be isolated to be transmitted using multiple priority access groups. For example, a 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 classify the configured logical channels into one or more (e.g., two) groups, and it may perform logical channel prioritization (e.g., separate) to multiplex one or more logical channels, or within each group, into separate packets.

[0349] One or more packets, or each packet, may be sent to a lower layer, for example, along with a priority access group indicator. One or more packets, or each packet, may be associated with a separate indicator, for example, indicating that preemption may be used to send that packet (for example, if supported).

[0350] Triggers for determining priority access groups 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 when it detects one or more of the following triggers: namely, the start / end of a D2D service (e.g., an emergency call), if D2D data may be available for transmission, if D2D data may be available for transmission, for example, at the beginning of a scheduling cycle, if the WTRU's functionality has changed (e.g., the WTRU can start and / or stop operating as a relay), or if a new D2D resource configuration may be provided from a higher layer.

[0351] Priority access groups can change. If a WTRU is able to decide to select a new priority access group and / or 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 earlier priority access groups for resource selection; determine which traffic types and logical channels or groups of logical channels can 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 of them; and perform one or more of the logical channel prioritization and / or packet generation actions for one or more of the logical channels that can belong to the selected priority access group.

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

[0353] While features and elements are described in the preceding paragraph in specific combinations, those skilled in the art will recognize that one or more features or elements, or each feature or element, may be used alone or in any combination with other features and elements. Furthermore, the methods described herein may be executed in computer programs, software, or firmware embedded in computer-readable media to be executed 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 run radio frequency transceivers, WTRUs, terminals, base stations, RNCs, or any host computer for use in a WTRU.

Claims

1. A first wireless transceiver unit (WTRU), A first scheduling assignment for a first sidelink data transmission is received from a second WTRU, wherein the first scheduling assignment includes the display of one or more first resources and the display of a first priority associated with the first sidelink data transmission. It is decided to send a second sidelink data transmission, and the second sidelink data transmission is associated with a second priority, and the second priority is lower than the first priority. The signal intensity associated with the first scheduling assignment is measured, To send the second sidelink data transmission, one or more resources are selected, and the first WTRU determines that one or more resources are available to send the second sidelink data transmission, at least on the basis that the signal strength associated with the first scheduling assignment is less than a threshold. Send a second scheduling assignment for the second sidelink data transmission, wherein the second scheduling assignment includes the display of one or more selected resources. A first WTRU equipped with a processor configured as follows.

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

3. The first WTRU according to claim 2, wherein at least one of the one or more resources is selected to send the second sidelink data transmission, based at least on the fact that the signal intensity associated with the first scheduling assignment is less than the threshold.

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

5. The first WTRU according to claim 4, wherein, for the second sidelink data transmission, one or more resources are excluded from resource selection, at least on the basis that the signal intensity associated with the first scheduling assignment is greater than the threshold.

6. The first WTRU according to claim 1, wherein the signal intensity associated with the first scheduling assignment corresponds to the signal intensity of one or more first resources displayed for the first sidelink data transmission.

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

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

9. The first WTRU according to claim 8, wherein, at least based on the receipt of the resource release indicator, one or more first resources are considered available to send the second priority data transmission.

10. The first WTRU according to claim 1, wherein the threshold is included in a configuration that is received by the first WTRU.

11. A method carried out by a first wireless transceiver unit (WTRU), Receiving a first scheduling assignment from a second WTRU for a first sidelink data transmission, wherein the first scheduling assignment includes an indication of one or more first resources and an indication of a first priority associated with the first sidelink data transmission. The decision to send a second sidelink data transmission is made such that the second sidelink data transmission is associated with a second priority, and the second priority is lower than the first priority. Measuring the signal intensity associated with the first scheduling assignment, Selecting one or more resources to send the second sidelink data transmission, wherein the first WTRU determines that one or more resources are available to send the second sidelink data transmission, at least on the basis that the signal strength associated with the first scheduling assignment is below a threshold, Sending a second scheduling assignment for the second sidelink data transmission, wherein the second scheduling assignment includes the display of one or more selected resources. Methods that include...

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

13. The method according to claim 12, wherein at least one of the one or more resources is selected to send the second sidelink data transmission, at least on the basis that the signal intensity associated with the first scheduling assignment is less than the threshold.

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

15. The method according to claim 14, wherein, for the second sidelink data transmission, one or more resources are excluded from resource selection, at least on the basis that the signal intensity associated with the first scheduling assignment is greater than the threshold.

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

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

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

19. The method according to claim 18, wherein, at least based on the receipt of the resource release indicator, it is considered that one or more first resources are available to send the second priority data transmission.

20. The method according to claim 11, wherein the threshold is included in the configuration received by the first WTRU.

Images