METHOD AND SYSTEM FOR SCHEDULING IN Uu-BASED INTER-VEHICLE COMMUNICATION

By modifying the SPS configuration in response to trigger events and aligning CAM transmission with the changed SPS resources, the method addresses the challenges of latency and resource management in Uu-based inter-vehicle communications, enhancing the efficiency and reliability of CAM message delivery.

JP2025069325AInactive Publication Date: 2025-04-30INTERDIGITAL PATENT HOLDINGS INC
View PDF 4 Cites 0 Cited by

Patent Information

Application Number
JP2025016073
Authority / Receiving Office
JP · JP
Patent Type
Applications
Current Assignee / Owner
Priority Date
2016-07-25
Filing Date
2025-02-03
Publication Date
2025-04-30
Estimated Expiration
Not applicable · inactive patent

AI Technical Summary

Technical Problem

Existing methods for aligning the generation and transmission of Cooperative Awareness Messages (CAMs) with Semi-Persistent Scheduling (SPS) resource timing in Uu-based inter-vehicle communications face challenges in meeting latency requirements and efficiently managing variable payload sizes and periodicity changes.

Method used

The method involves sending an instruction to modify the SPS configuration based on trigger events, allowing for changes in scheduling interval and offset, and reconfiguring the SPS to align CAM transmission with the changed SPS resources, ensuring efficient use of SPS resources and minimizing latency.

Benefits of technology

This approach enables more efficient use of SPS resources, reduces latency in CAM message delivery, and adapts to changes in CAM generation periodicity and payload size, thereby improving the reliability and effectiveness of inter-vehicle communications.

✦ Generated by Eureka AI based on patent content.

Smart Images

  • Figure 2025069325000001_ABST
    Figure 2025069325000001_ABST
Patent Text Reader

Abstract

To provide a method, an apparatus, and a system for aligning Coordination Aware Message (CAM) generation and transmission to Semi-Persistent Scheduling (SPS) resource timing on the basis of an SPS configuration.SOLUTION: A method for operation in a wireless transmit / receive unit (WTRU) 502 includes transmitting 506 a request for SPS resources from the WTRU to an evolved Node B (eNB) including a periodicity of the requested SPS resources and a time offset indicating when the WTRU expects to have SPS resources allocated, and receiving an SPS configuration from the eNB in response to the transmitted request for SPS resources by the WTRU. The time offset includes a subframe number (SFN) offset relative to SFN 0 of the WTRU.SELECTED DRAWING: Figure 5
Need to check novelty before this filing date? Find Prior Art

Description

[Technical field]

[0001] The present invention relates to a method and system for scheduling in Uu-based inter-vehicle communications. [Background technology]

[0002] CROSS-REFERENCE TO RELATED APPLICATIONS This application claims the benefit of U.S. Provisional Patent Application No. 62 / 315,262, filed March 30, 2016, and U.S. Provisional Patent Application No. 62 / 366,152, filed July 25, 2016, the contents of which are incorporated herein by reference.

[0003] Vehicle-to-vehicle (V2V), vehicle-to-infrastructure (V2I), and vehicle-to-pedestrian (V2P) (collectively referred to as vehicle-to-everything (V2X)) are vehicle communication systems in which vehicles and roadside units are communicating nodes in a communication network. These nodes provide each other with information such as safety warnings and traffic information. In a cooperative approach, vehicle communication systems can be more effective in avoiding accidents and traffic congestion than if each vehicle tried to solve the problem individually.

[0004] Direct device-to-device (D2D) communications are beginning to be supported by major standardization bodies such as the Institute of Electrical and Electronics Engineers (IEEE) or the Third Generation Partnership Project (3GPP). In the case of 3GPP and Long Term Evolution (LTE) based radio access, support for D2D communications is being introduced to enable cost-efficient, high-capacity public safety communications using LTE technology. This is motivated firstly by the desire to harmonize radio access technologies across jurisdictions to lower the capital expenditures (CAPEX) and operating expenses (OPEX) of radio access technologies available for use in public safety (PS) type applications. This is motivated secondly by LTE as a scalable wideband wireless solution enabling efficient multiplexing of different service types such as voice and video.

[0005] Because PS applications typically require wireless communication in areas that are often not within the radio coverage of LTE networks, for example, in tunnels, deep underground, or after a catastrophic system outage, there is a need to support D2D communication for PS in the absence of any operating network or prior to the arrival of ad-hoc deployed wireless infrastructure. However, even when operating in the presence of an operating network infrastructure, PS communications may still generally require higher reliability than commercial services.

[0006] V2X communication standards and technologies may be developed based on current D2D LTE specifications along with potential extensions to LTE, both D2D and non-D2D, to meet the requirements of services subgrouped in the 3GPP Technical Specification Group on Service and System Aspects (SA1). Summary of the Invention [Problem to be solved by the invention]

[0007] A method, apparatus and system are provided that aligns CAM generation and transmission to SPS resource timing based on an SPS configuration. [Means for solving the problem]

[0008] The present invention provides a method, apparatus, and system for aligning CAM generation and transmission to SPS resource timing based on a semi-persistent scheduling (SPS) configuration, the method, apparatus, and system including: transmitting an instruction to change a semi-persistent scheduling (SPS) configuration to a Node B based on a trigger event, the instruction to change the SPS configuration including a request to change at least one of a scheduling interval and an offset of a current SPS configuration; reconfiguring a current SPS configuration based on the instruction to change the SPS configuration; and transmitting a coordination awareness message (CAM) using SPS resources according to the changed SPS configuration.

[0009] A method for operation in a wireless transmit / receive unit (WTRU) may comprise transmitting a request for semi-persistent scheduling (SPS) resources from the WTRU to an evolved Node B (eNB) including a periodicity of the requested SPS resources and a time offset indicating a time when the WTRU expects to have SPS resources assigned. The method may further comprise receiving an SPS configuration in response to the transmitted request for SPS resources from the eNB by the WTRU. The time offset of the transmitted request may include a subframe number offset relative to system frame number (SFN) 0 of the WTRU. The received SPS configuration may correspond to a PC5 interface. The SPS configuration may be received via a physical downlink control channel (PDCCH). Effect of the Invention

[0010] The present invention provides a method, apparatus and system that aligns CAM generation and transmission to SPS resource timing based on an SPS configuration. [Brief description of the drawings]

[0011] A more detailed understanding may be had from the following description, given by way of example in conjunction with the accompanying drawings, in which:

[0012] [Figure 1A] FIG. 1 is a system diagram of an example communication system in which one or more embodiments may be implemented. [Figure 1B] FIG. 1B is a diagram of an example wireless transmit / receive unit (WTRU) that may be used within the communications system of FIG. 1A. [Figure 1C] FIG. 1B is a system diagram of an example radio access network and core network that may be used within the communication system of FIG. 1A. [Diagram 2] FIG. 2 is an example timeline diagram of CAM timing. [Figure 3A] 1 is a diagram of an example 4-bit interval value indicator used to signal one of ten or more desired pre-configured SPS intervals. [Figure 3B] FIG. 1 is a diagram of an example MAC Control Element (CE) design with interval indicator values ​​and system frame numbers (SFNs). [Figure 4] 1 is a diagram of an example MAC PDU comprising multiple MAC CEs. [Diagram 5] FIG. 13 is an exemplary procedure diagram for a requested offset or offset change. [Figure 6] FIG. 13 is an exemplary procedure diagram of an instruction to change an SPS configuration. [Figure 7] 1 is a flow diagram of a method for truncated SPS reconfiguration using an acknowledgement message. [Figure 8] 1 is a list of exemplary trigger events for SPS reconfiguration. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

[0013] 1A is a diagram of an example communication system 100 in which one or more disclosed embodiments may be implemented. The communication system 100 may be a multiple access system that provides multiple wireless users with content, such as voice, data, video, messaging, broadcasts, etc. The communication system 100 may enable multiple wireless users to access such content through sharing of system resources, including wireless bandwidth. For example, the communication system 100 may employ one or more channel access methods, such as Code Division Multiple Access (CDMA), Time Division Multiple Access (TDMA), Frequency Division Multiple Access (FDMA), Orthogonal FDMA (OFDMA), Single Carrier FDMA (SC-FDMA), etc.

[0014] 1A, the communications system 100 may include wireless transmit / receive units (WTRUs) 102a, 102b, 102c, 102d, a radio access network (RAN) 104, a core network 106, a public switched telephone network (PSTN) 108, the Internet 110, and other networks 112, although it will be appreciated that the disclosed embodiments contemplate any number of WTRUs, base stations, networks, and / or network elements. Each of the WTRUs 102a, 102b, 102c, 102d may be any type of device configured to operate and / or communicate in a wireless environment. By way of example, the WTRUs 102a, 102b, 102c, 102d may be configured to transmit and / or receive wireless signals and may include user equipment (UE), mobile stations, fixed or mobile subscriber units, pagers, cellular phones, personal digital assistants (PDAs), smartphones, laptops, netbooks, personal computers, wireless sensors, consumer electronic devices, and the like.

[0015] The communications system 100 may also include a base station 114a and a base station 114b. Each of the base stations 114a, 114b may be any type of device configured to wirelessly interface with at least one of the WTRUs 102a, 102b, 102c, 102d to facilitate access to one or more communications networks, such as the core network 106, the Internet 110, and / or other networks 112. By way of example, the base stations 114a, 114b may be a base transceiver station (BTS), a Node B, an eNode B, a home Node B, a home eNode B, a site controller, an access point (AP), a wireless router, etc. Although the base stations 114a, 114b are each shown as a single element, it will be appreciated that the base stations 114a, 114b may include any number of interconnected base stations and / or network elements.

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

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

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

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

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

[0021] The base station 114b in FIG. 1A may be, for example, a wireless router, a Home NodeB, a Home eNodeB, or an access point, and may utilize any suitable RAT to facilitate wireless connectivity in a localized area, such as an office, a home, a vehicle, a campus, etc. In one embodiment, the base station 114b and the WTRUs 102c, 102d may implement a radio technology, such as IEEE 802.11, to establish a wireless local area network (WLAN). In another embodiment, the base station 114b and the WTRUs 102c, 102d may implement a radio technology, such as IEEE 802.15, to establish a wireless personal area network (WPAN). In yet another embodiment, the base station 114b and the WTRUs 102c, 102d may utilize a cellular-based RAT (e.g., WCDMA, CDMA2000, GSM, LTE, LTE-A, etc.) to establish a picocell or femtocell. As shown in FIG. 1A, the base station 114b may have a direct connection to the Internet 110. Therefore, the base station 114 b may not need to access the Internet 110 via the core network 106 .

[0022] The RAN 104 may be in communication with a core network 106, which may be any type of network configured to provide voice, data, application, and / or Voice over Internet Protocol (VoIP) services to one or more of the WTRUs 102a, 102b, 102c, 102d. For example, the core network 106 may provide call control, billing services, mobile location-based services, prepaid telephony, Internet connectivity, video distribution, and / or perform high-level security functions such as user authentication. Although not shown in FIG. 1A, it will be appreciated that the RAN 104 and / or the core network 106 may be in direct or indirect communication with other RANs employing the same RAT as the RAN 104 or a different RAT. For example, in addition to being connected to the RAN 104, which may utilize E-UTRA radio technology, the core network 106 may also be in communication with another RAN (not shown) employing GSM radio technology.

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

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

[0025] Figure 1B is a system diagram of an example WTRU 102. As shown in Figure 1B, the WTRU 102 may include a processor 118, a transceiver 120, a transmit / receive element 122, a speaker / microphone 124, a keypad 126, a display / touchpad 128, non-removable memory 130, removable memory 132, a power source 134, a Global Positioning System (GPS) chipset 136, and other peripherals 138. It will be appreciated that the WTRU 102 may include any sub-combination of the above elements while remaining consistent with an embodiment.

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

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

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

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

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

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

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

[0033] The processor 118 may further be coupled to other peripherals 138, which may include one or more software and / or hardware modules that provide additional features, functionality, and / or wired or wireless connectivity. For example, the peripherals 138 may include an accelerometer, an e-compass, a satellite transceiver, a digital camera (for photos or videos), a Universal Serial Bus (USB) port, a vibration device, a television transceiver, a hands-free headset, a Bluetooth module, a frequency modulation (FM) radio unit, a digital music player, a media player, a video game player module, an Internet browser, etc.

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

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

[0036] Each of the eNodeBs 140a, 140b, 140c may be associated with a particular cell (not shown) and may be configured to handle radio resource management decisions, handover decisions, scheduling of users on the uplink and / or downlink, etc. As shown in FIG 1C, the eNodeBs 140a, 140b, 140c may communicate with one another over an X2 interface.

[0037] 1C may include a mobility management entity gateway (MME) 142, a serving gateway 144, and a packet data network (PDN) gateway 146. Although each of the above elements is shown as part of the core network 106, it will be appreciated that any one of these elements may be owned and / or operated by an entity other than the core network operator.

[0038] The MME 142 may be connected to each of the eNodeBs 140a, 140b, 140c in the RAN 104 via an S1 interface and may act as a control node. For example, the MME 142 may be responsible for authenticating users of the WTRUs 102a, 102b, 102c, activating / deactivating bearers, selecting a particular serving gateway during initial attachment of the WTRUs 102a, 102b, 102c, etc. The MME 142 may also provide a control plane function for switching between the RAN 104 and other RANs (not shown) that employ other radio technologies, such as GSM or WCDMA.

[0039] The serving gateway 144 may be connected to each of the eNodeBs 140a, 140b, 140c in the RAN 104 via an S1 interface. The serving gateway 144 may generally route and forward user data packets to and from the WTRUs 102a, 102b, 102c. The serving gateway 144 may also perform other functions, such as anchoring the user plane during inter-eNodeB handover, triggering paging when downlink data is available for the WTRUs 102a, 102b, 102c, managing and storing the context of the WTRUs 102a, 102b, 102c, etc.

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

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

[0042] The other network 112 may further be connected to an IEEE 802.11-based wireless local area network (WLAN) 160. The WLAN 160 may include an access router 165. The access router may include a gateway function. The access router 165 may be in communication with multiple access points (APs) 170a, 170b. Communication between the access router 165 and the APs 170a, 170b may be via wired Ethernet (IEEE 802.3 standard) or any type of wireless communication protocol. The AP 170a communicates wirelessly over an air interface with the WTRU 102d.

[0043] Vehicle-to-Vehicle (V2V), Vehicle-to-Infrastructure (V2I), and Vehicle-to-Pedestrian (V2P) (collectively referred to as Vehicle-to-Everything (V2X)) are vehicle communication systems in which vehicles and roadside units are communicating nodes in a communication network that provides each other with information such as safety warnings and traffic information. As a cooperative approach, vehicle communication systems can be more effective at avoiding accidents and traffic congestion than if each vehicle were to attempt to solve these problems individually.

[0044] In general, vehicular networks are considered to include two types of nodes: vehicles and roadside stations. Both are dedicated short-range communications (DSRC) devices. DSRC typically operates in the 5.9 GHz band with a bandwidth of 75 MHz and a pseudorange of about 1000 meters.

[0045] Standards for vehicular communications, including V2V, V2I, and V2P, may be developed by adapting current LTE specifications. For example, existing device-to-device (D2D), e.g., V2V communications using the ProSe framework may be considered.

[0046] V2X communication requirements have been developed in 3GPP by SA1. In particular, these requirements call for the transmission of short messages, on the order of 50 to several hundred bytes, with AS-level high reliability (e.g., up to 90%) and low latency, e.g., as short as 100 ms, to support specific use cases such as forward collision warning, control loss warning, and emergency stop.

[0047] D2D communications are being developed for public safety (PS) communications using LTE technology. Because PS applications typically require wireless communications in areas that are often not within the radio coverage of LTE networks, for example, in tunnels, deep underground, or after catastrophic system outages, there is a need to support D2D communications for PS in the absence of any operating network or prior to the arrival of ad-hoc deployed wireless infrastructure. However, even when operating in the presence of operating network infrastructure equipment, PS communications may still generally require higher reliability than commercial services.

[0048] For example, the PS type application between the first responder may include at least a direct push-to-talk voice service using multiple talkgroups. Additionally, the PS type application may include services such as video push or download to efficiently utilize the capabilities that LTE broadband radio provides.

[0049] It is expected that, when deployed, D2D communication may be available not only for PS-type applications but also for commercial use cases. An example may be the case of power companies, who often also need support for two-way wireless communication in areas not covered by network infrastructure. Furthermore, D2D services such as discovery may be a suitable signaling mechanism to enable proximity-based services and traffic offloading using LTE-based radio access in commercial use cases.

[0050] D2D communications using LTE-based radio access may be designed to operate in network-controlled and WTRU-autonomous modes, hereinafter referred to as Mode 1 and Mode 2, respectively. Mode 1 (i.e., network-controlled) may be possible only under certain conditions, e.g., only when the D2D terminal is within radio range of an LTE base station. If the WTRU is unable to communicate with an LTE base station, the D2D terminal may revert to Mode 2 (i.e., WTRU-autonomous) operation. In this case, it will primarily use channel access parameters pre-stored in the terminal itself.

[0051] For D2D communication using Mode 1, the LTE base station may reserve a selected set of uplink (UL) subframes to enable D2D transmission. The LTE base station may also announce with associated parameters a set of UL subframes in which D2D communication for neighbor cells or Mode 2 terminals may be received. Not all LTE system bandwidth (BW) may be available for D2D transmission in reserved subframes for D2D. When operating in Mode 1, radio resources for D2D communication may be granted to the D2D terminal by the serving cell. A D2D grant from the network may be preceded by a UL transmission by the terminal on a cellular UL channel indicating to the base station the amount of available D2D data. A D2D grant received by the D2D terminal from the LTE base station on a cellular DL channel allows the D2D terminal to use some selected radio resources, i.e., some radio blocks (RBs) occurring during some subframes over a certain scheduling period.

[0052] A D2D terminal may transmit a scheduling assignment (SA) message in a first set of one or more D2D subframes and then transmit D2D data in a second set of D2D subframes during the scheduling period. The scheduling assignment may include an identifier field, a modulation and coding scheme (MCS) field, a resource indicator, and a timing advance (TA) field, among others. The D2D data packet may include a medium access control (MAC) header with source and destination addresses, among others. Multiple logical channels may be multiplexed and sent by the WTRU as part of a single transport block (TB) in a given D2D subframe.

[0053] For D2D communication using Mode 2, the D2D terminal may autonomously select the time / frequency radio resources. Channel access parameters such as subframes to use with the transmission of SA control messages and corresponding D2D data, scheduling periods or monitoring subframes may be pre-configured and stored on the D2D terminal. Except for the indication of the previous UL traffic volume and the phase of DL D2D grants, Mode 2 terminals may follow the same transmission behavior as Mode 1 terminals and will also transmit SA followed by D2D data during the scheduling period.

[0054] For both Mode 1 and Mode 2 of D2D communication, the D2D terminal may also transmit auxiliary D2D signals, such as, for example, D2D synchronization signals and channel messages, to help the receiver demodulate those transmissions.

[0055] D2D communication using LTE-based radio access may carry voice channels or data packets or data streams. A special case of D2D communication is the D2D discovery service. D2D discovery, unlike voice channels, may generally only require small packet transmissions that can often fit into one, two or at most a few subframes. For example, these packets may contain application data announcing the availability of a device or software (SW) application to participate in D2D data exchange with nearby terminals.

[0056] D2D discovery may or may not use the same channel access protocol, such as the protocol used for D2D communication of voice or general D2D data. For D2D discovery when in the coverage of an LTE base station, D2D discovery resources may be allocated separately from the resources used for D2D communication with voice or general D2D data. Radio resources for D2D discovery messages may be autonomously selected by the D2D terminal from a set of resources reserved by the eNB, and may be periodically repeating time-frequency radio resources in several UL subframes (e.g., Type 1 discovery), or they may be explicitly assigned to the D2D terminal by the LTE serving cell (e.g., Type 2 discovery). The latter is similar to D2D communication mode 1. When transmitting a D2D discovery message, transmission of a scheduling assignment may not be necessary. However, in some cases, even D2D terminals that only transmit D2D discovery messages may still need to transmit auxiliary D2D synchronization signals to assist the receiver.

[0057] 3GPP is currently evaluating the feasibility of V2X communications based on current D2D LTE specifications in addition to identifying potential extensions to LTE (both D2D and potentially non-D2D) required to meet SA1 requirements. As part of this feasibility study, 3GPP has identified four main V2X scenarios:

[0058] Scenario 1 supports V2V operation based solely on PC5, which involves transmission of V2X data from a source WTRU (e.g., a vehicle) to a destination WTRU, e.g., another vehicle, a road infrastructure device, a pedestrian, etc., via ProSe direct communication over the PC5 interface between the WTRUs (sidelink).

[0059] Scenario 2 supports V2V operation based solely on Uu, which involves transmission of V2X data from a source WTRU (e.g., a vehicle) to a destination WTRU (e.g., another vehicle, road infrastructure, pedestrians, etc.) via an eNB across the Uu interface (uplink and downlink).

[0060] Scenario 3A includes a WTRU transmitting a V2X message to other WTRUs in the sidelink. One of the receiving WTRUs is a WTRU type roadside unit (RSU) that receives the V2X message in the sidelink and transmits it to the E-UTRAN in the uplink. The E-UTRAN receives the V2X message from the WTRU type RSU and then transmits it in the downlink to multiple WTRUs in the local area.

[0061] Scenario 3B includes a WTRU transmitting a V2X message in the uplink to an E-UTRAN, which transmits the V2X message to one or more WTRU-type RSUs, which then transmit the V2X message in the sidelink to other WTRUs.

[0062] LTE may use semi-persistent scheduling (SPS) as its form of semi-static resource allocation used to avoid the scheduling overhead associated with dynamic scheduling of resources for services with periodically occurring transmissions of relatively small payloads (e.g., VoIP). SPS is possible for both uplink and downlink transmissions.

[0063] In uplink SPS, when new data arrives in the WTRU's buffer, the WTRU may report an indication of its buffer status using a Buffer Status Report (BSR) message. A BSR control element typically contains a logical channel group ID and one or more fields corresponding to the buffer size. Since any sidelink buffered data is intended for transmission to another WTRU and not to the reporting eNB, the sidelink-specific BSR may also contain a destination index.

[0064] In SPS, the terminal may provide scheduling on the physical download control channel (PDCCH) to indicate a grant that is valid every N subframes. The periodicity or value of the N SPS resources is given by radio resource control (RRC) signaling, while the resource activation / deactivation and details are given by PDCCH signaling using the SPS Cell Radio Network Temporary Identifier (C-RNTI). Dynamic scheduling commands occurring during the same subframe as the SPS resources may take precedence over the SPS resources. Such behavior is useful if the regular resources assigned to the WTRU need to be increased from time to time.

[0065] SPS retransmissions may always be dynamically scheduled in the downlink, while in the uplink they may be dynamically scheduled or may follow semi-persistently assigned subframes. SPS is further supported only in the primary cell (PCell) or (in case of dual connectivity (DC)) the primary secondary cell (PSCell).

[0066] One of the basic message types transmitted for V2X as V2X traffic is the cooperative awareness message (CAM). CAM messages contain cooperative awareness information exchanged between road users and roadside infrastructure to inform them of the location, dynamics and attributes of other vehicles. Periodic exchange of such information can be key for several road safety and traffic efficiency applications.

[0067] A CAM is composed of certain containers that may be mandatory or optional. Each CAM message may contain at least one basic container containing basic information related to the originating Intelligent Transportation System Station (ITS-S) and one high-frequency container containing highly dynamic information of the originating ITS-S. In addition, a CAM message may also contain one low-frequency container containing static, not very dynamic information of the originating ITS-S and one or more special containers containing information specific to the vehicle role of the originating vehicle's ITS-S, i.e., for special vehicles.

[0068] Some example ITS elements include active traffic management systems, traffic cameras for monitoring weather, traffic congestion, or other events, variable message signs that may include Amber Alerts or other messages, road information radios, road and weather information systems, ramp meters, traffic data collectors, and traffic management centers.

[0069] The transmission of CAM messages may be periodic with some deviation or adjustment in duration based on the vehicle heading, the vehicle speed, the vehicle position, and the time since the last generation of a CAM message. Additionally, an infrequent container must be included in a CAM if the time since the last generation of a CAM with the same infrequent container is greater than or equal to 500 ms. This same rule applies to special containers.

[0070] To adopt V2X communications, E-UTRAN must be able to support a maximum latency of 100ms for the majority of use cases. Although the pre-collision detection use case has a more stringent requirement of 20ms, the base assumption in 3GPP for the standardization of any V2X related enhancements is the 100ms requirement for RAN related latency.

[0071] SPS is a good candidate for transmission of V2V messages in the UL in scenarios 2 and 3 described above due to the mostly periodic nature of CAM traffic. However, UL capacity on Uu may be difficult to meet below 40 ms SPS period due to the large number of vehicles in urban scenarios that would need to transmit in the uplink, and therefore longer SPS periods may need to be considered.

[0072] A method is provided for determining, reporting and receiving indicators of SPS periodicity and offset changes. The latency in transmitting a CAM message by the E-UTRAN may comprise one or more of the following factors: As a first component, the latency may consist of the time between when the CAM message is generated by the V2X application and when the next UL SPS resource is available to be assigned to the WTRU. As a second component, the latency may consist of the time required to receive and process the CAM message in the network, and may further depend on whether the CAM message is sent to the core network or the processing remains in the eNB. As a third component, the latency may consist of the time required to transmit the message in a downlink channel to a destination WTRU using Single-cell Point-to-Multipoint (SC-PTM), evolved Multimedia Broadcast Multicast Service (eMBMS), or unicast scheduling.

[0073] As the SPS period increases, the portion of the latency due to the first component increases. Such an increase can only be avoided if the generation of the CAM messages is truly periodic and if the SPS period can be aligned with the generation of the CAM messages.

[0074] Based on the frequency of CAM generation, true periodicity may not be assumed, and the pattern of CAM generation may be subject to changes in periodicity and offset changes compared to the SPS pattern.

[0075] Changes in periodicity may occur during the pattern of CAM generation. For example, the interval between CAM generation may be dynamically changed, moving between 100 ms when the vehicle's position, heading, and speed are changing and 1 second when the vehicle's position, heading, and speed are not changing. Furthermore, for some CAM generation intervals specified by the Cooperative Awareness (CA) Basic Service, there may be periods during which the periodicity may be something between these values. Thus, the period of CAM generation may dynamically change over time and theoretically take any period between 100 ms and 1 second.

[0076] Changes in offset may occur during the pattern of CAM generation: transitions between one CAM interval and another may result in changes in the offset between message generation and a fixed SPS schedule when such intervals are not multiples of 100 ms.

[0077] These changes in the pattern of CAM message generation therefore result in an increase in the first latency component, potentially failing to meet the 100 ms latency requirement when SPS is used.

[0078] Furthermore, there can be variable payload sizes. SPS is best suited for periodic traffic with fixed resource allocation sizes, such as Voice over Internet Protocol (VoIP). Although message size deviations can be easily handled through dynamic scheduling, frequent dynamic scheduling can result in increased scheduling overhead and significantly reduce the benefits of SPS. Such reduction in benefits can be even more pronounced in the case of V2V traffic, when the assumption (at least for urban scenarios) is that there is a density of vehicles and they need to receive such dynamic scheduling periodically. On the other hand, over-allocating resources results in a waste of SPS resources that can be utilized by the scheduler for other purposes.

[0079] CAM messages can be about 190 bytes when they contain only a frequent container, and about 300 bytes when they contain a frequent container and one or more infrequent containers. CAM messages with special containers can also deviate from these sizes. Thus, the size of CAM messages is quite variable. The allocation size of the SPS can be defined in a more dynamic way without relying solely on dynamic scheduling.

[0080] It should be understood that the term D2D data may refer to any type of D2D related communication between D2D terminals. For example, without loss of generality, D2D data may include data packets, such as data packets carrying voice or segments thereof, may include Internet Protocol (IP) packets or segments thereof, such as IP packets used for file download or upload, streaming or two-way video, may include D2D control signaling, and / or may include D2D discovery or service or availability messages. Furthermore, although the embodiments described herein are described in the general context of 3GPP D2D communication features, the concepts may be applicable to other features, such as, for example, D2D discovery.

[0081] This specification introduces the following concepts: the WTRU may send a requested offset or offset change of the SPS; the WTRU may send an indication to change the SPS configuration; the WTRU may send an indication to release certain resources; multiple SPS configurations may be given and configuration activation / deactivation methods are disclosed; the size of the SPS message may be configured through the application layer; the size of the SPS message may be associated with a QCI for a logical channel; changes in allocation size may be piggybacked on the SPS transmission; methods for periodic increase in size of the SPS allocation are disclosed; the WTRU may request SPS based on a trigger from an application; an extension of the SPS configuration may be received by the WTRU. The extension may include the format and timing of the assistance information, the allowed offsets that the WTRU may request to change, an index of the SPS configuration, and the allowed logical channel or resource configuration for the SPS configuration. A new trigger for the sidelink BSR may be given to send the offset change information. Application-based, access stratum (AS)-calculated triggers for sending SPS configuration / offset changes or activation / deactivation may be based on higher layer information. Logical channel prioritization (LCP) may be applied to SPS grants based on the association of logical channels with SPS configurations. The WTRU may select a single SPS grant in the case of simultaneous grants. An LTE adaptation layer is disclosed for enabling / disabling SPS usage, providing timing based on timing compensation, and providing spacing information.

[0082] As described herein, the term "WTRU" may refer to a single D2D-enabled device, which may be an actual mobile device, a vehicle with D2D communication capability, and / or a roadside unit intended to improve the performance of a V2X system. The term "WTRU" may also refer to a mobile device that directly communicates with an eNB. Similarly, the term "eNB" refers to a conventional eNB employed in LTE infrastructure communication, which may provide communication services for D2D communication in its coverage. The eNB may be deployed on a cellular tower or may itself be deployed as a roadside unit, in the latter case, the eNB may have a function limited to only D2D communication.

[0083] As described further herein, reference is made to CAM messages with particular reference to V2V-related application messages transmitted over the AS air interface. In the described embodiment, the CAM messages may represent any type of higher layer message that the WTRU may need to transmit using SPS over either the uplink or sidelink. Such messages may have time-critical or delay-sensitive properties. Such messages may further be considered to be periodic during most of the time or for a significant amount of time, and may occasionally change duration, timing (offset), or size of the message.

[0084] 2 illustrates an example timeline diagram of CAM timing 200. In view of the example timeline illustrated in FIG. 2, potential problems associated with using a fixed (e.g., 100 ms) period 202 for SPS can become apparent for a highly plausible high traffic scenario for a vehicle. In this example, the vehicle performs the following actions, identified by the following example timeline:

[0085] After a period of time during which the vehicle satisfies a first condition, e.g., a change in speed, position or heading, the vehicle stops satisfying condition 1, e.g., the vehicle stops 204. The vehicle begins to move again 206 and again begins to satisfy condition 1. The vehicle may begin to decelerate 208. The vehicle stops satisfying condition 1 and stops 210. The vehicle again begins to satisfy condition 1 160 ms after the last CAM, e.g., begins to move again, albeit briefly 212. The CAMs are then spaced 160 ms apart for three intervals until they return to occurring at 1 second intervals.

[0086] Thus, timeline 200 shows the resulting timing of the CAM using a 100 ms period SPS configuration. This configuration may potentially result in a large amount of SPS resources not being used by the WTRU 214 216 that cannot be reused by the scheduler. Although the resources may be implicitly released after several null transmissions by the WTRU, frequent transitions between the two states may still result in some resource wastage, and the WTRU may still need to communicate with the eNB to reallocate resources. Furthermore, potentially large waiting delays (ranging from 30 ms to 90 ms) may result under this configuration. These large waiting delays would need to be added to the overall E-UTRAN latency for V2X messages, missing the 100 ms requirement.

[0087] Although the above problems have been described with reference to CAM messages, it will be appreciated that problems may arise for other types of application-related traffic, such as VoIP, real-time control, etc. Thus, the embodiments disclosed herein may be applied not only to V2V use cases, but also to any use case where the traffic exhibits properties similar to CAM.

[0088] An SPS configuration is described in which the WTRU may request the use of SPS and / or the SPS configuration is given by the eNB. For example, the WTRU may request the use of SPS from the eNB. Such a request may be sent by the WTRU via RRC signaling. For example, a WTRU requesting SPS from the eNB may do so using a WTRUSidelinklnformation RRC message. The WTRU, in one embodiment, may send a request for use of SPS as a result of a trigger from a higher layer using an adaptation layer as described herein.

[0089] The WTRU may include one or more information elements related to SPS parameters in a request for an SPS configuration. For example, the WTRU may include information related to one or more desired SPS configurations, each including one or more of the periodicity and / or offset of the SPS configuration, the size of the transmission (e.g., transport block size (TBS)), the number of resource blocks RB, etc. In another example, the WTRU may include information related to the desired parameters of one or more requested SPS configurations in the form of a set of indexes, each pointing to a row in a preconfigured table, where each row in the table lists a set of desired SPS parameters for that desired SPS configuration.

[0090] In response to an SPS request from the WTRU, the eNB may send the SPS configuration to the WTRU. Alternatively, the eNB may send the SPS configuration to the WTRU without an SPS request and thus may send the SPS configuration autonomously or due to some other trigger.

[0091] In transmitting messages over Uu, the WTRU may utilize the existing uplink SPS in LTE. Additionally, a similar SPS configuration may be configured for sidelink SPS, where the sidelink SPS configuration may be sent via RRC messaging, or a combination of RRC messaging with MAC control element (CE) and PHY messaging on the PDCCH. The uplink or sidelink SPS configuration may further include a configuration of WTRU assistance information (e.g., configuration information) and / or a sidelink configuration.

[0092] WTRU assistance information includes information sent by the WTRU to the eNB to assist the eNB in ​​adjusting SPS parameters. Various types of configuration information for the WTRU assistance information are possible. The WTRU may receive a configuration of the WTRU assistance information related to whether assistance information may be provided to the eNB related to the SPS schedule, what type of assistance information may be provided (e.g., timing, duration), and how to send the information. The configuration of the WTRU assistance information may enable or disable the WTRU to transmit SPS scheduling assistance information. The WTRU may receive a list of possible timing offsets for the SPS resource pattern, where the offsets may be defined for a particular SFN / subframe number and / or relative to the start of the scheduling period. The WTRU may receive a list of possible SPS periods / intervals that it may select or request a change. The list of possible SPS periods / intervals may be a subset of possible SPS periods that the WTRU may support or that the eNB may configure or assign to a given WTRU. The WTRU may only potentially request a change to one of the eNB-configured lists of periodicities. The WTRU may receive a configuration of resources (e.g., UL) to be used for sending the assistance information. For example, the assistance information may be sent using a dedicated SR resource configured by the eNB specifically for this purpose. The WTRU may receive an allowed time instance and frequency at which the assistance may be sent. For example, the WTRU may be configured to provide assistance at the end of each scheduling period or periodically based on a period configured by the eNB.

[0093] In the sidelink, an SPS configuration of subframes in each scheduling period corresponding to SPS resources may be given, which may be the same in each scheduling period and may further define the subframes for retransmission of data transmitted using SPS as well as the number of retransmissions required.

[0094] The WTRU may receive a list of possible SPS resource configurations that may be available in an SPS configuration. This list may be implemented using a set of indexes that point to a predefined lookup table. The WTRU may activate one of the possible SPS configurations from the list. Alternatively, the WTRU may have multiple SPS configurations active simultaneously.

[0095] A resource configuration of an SPS configuration or each configuration in a list of SPS configurations may be given. For example, each SPS configuration may correspond to a particular pattern of SPS resources with periodicity (i.e., interval), timing offset, allocation size, actual resources (resource blocks) used or pattern of allocation sizes. The pattern of allocation sizes may be defined such that one in a particular number of SPS resources has a difference (i.e., increase or decrease) in the amount of resources relative to the SPS allocation size. For sidelink SPS, the resource configuration may be configured as for uplink SPS, where the interval / period is configured during RRC and the timing / offset and resource configuration may be indicated by the eNB, e.g., by PHY layer signaling, to the WTRU. For sidelink, the PHY layer signaling may be a PDCCH with DCI format 5 and sent using the SPS C-RNTI configured in the RRC layer. Alternatively, in sidelink SPS, all resource configurations may be sent in RRC messaging (e.g., intervals, offsets, and allocation sizes and / or allocation patterns may be sent via RRC messaging).

[0096] The SPS configuration may further include identification information of data that the WTRU should transmit or prioritize when using each particular SPS configuration, which may be in the form of allowed logical channels, logical channel groups, priorities (e.g., ProSe Per-Packet Priority (PPPP)), radio bearers, application IDs, QCIs, etc. For example, a WTRU may be configured with multiple SPS configurations, each SPS configuration to be utilized for transmission of data for a particular logical channel or logical channel group.

[0097] The SPS configuration may further include an identification of the sidelink destination ID to which the SPS configuration applies.

[0098] A change in SPS timing is given. A change in offset for the WTRU or SPS sending the requested offset is given. As shown in the timeline shown in Figure 2, the generation of the CAM message should be aligned to the SPS resource timing to avoid additional delay for the delivery of the CAM message associated with waiting for the next SPS resource to transmit the pending CAM. Under the assumption of the same interval for both CAM and SPS, the waiting delay will be zero.

[0099] However, this cannot be guaranteed using current SPS mechanisms since the SPS offset configured by the eNB (i.e., the timing of PDCCH grants using SPS C-RNTI if UL SPS) is completely determined by the eNB.

[0100] In one example, the WTRU may send a desired starting subframe (i.e., offset) for SPS resources to the eNB to enable the eNB to trigger allocation / reallocation of SPS resources so that it is aligned to the generation of the CAM message. In particular, the WTRU may send a time offset to the eNB, e.g., in the form of a system frame number (SFN) number and / or subframe index indicating the time at which it expects to have available SPS resources (to start). The time offset (or "offset") may also be sent implicitly to the eNB by assuming that the SFN and / or subframe is a fixed, predefined number of subframes following the transmission of a signal by the WTRU to the eNB.

[0101] Alternatively, the WTRU may indicate to the eNB to delay or shift the current offset of the SPS by a certain amount of time. For example, the WTRU may be pre-configured with an SPS configuration and a specific time offset or starting point of the resources for that SPS configuration. The WTRU may indicate to the eNB to shift, delay, or advance the timing or starting point for that SPS configuration by a certain number of subframes relative to the current timing of the resources.

[0102] The WTRU may be configured with multiple timing options. For example, to reduce signaling related to a requested offset change by the eNB, the WTRU may be further configured with a set of possible timing offsets by the eNB, where one particular timing offset may be active at a given time, and the WTRU may request an alternative timing offset in a requested offset change message.

[0103] The WTRU may receive multiple possible offsets in the RRC message configuring the SPS, which may be indicated as offsets from a specific SFN / subframe defined or provided in the same configuration, or as offsets from an initial resource configuration in a PDCCH message indicated by the SPS C-RNTI that may allocate SPS resources for the configuration for the first time.

[0104] The WTRU may also receive or be associated with an index to each of the possible offsets in the RRC message.

[0105] When sending a requested offset change to the eNB, the WTRU may indicate the desired offset it wants to use by indicating an index associated with one of the configured offsets.

[0106] FIG. 3A discloses the use of a 4-bit interval value indicator 300. With 4 bits, a value 302 may represent the interval size. Assuming 4 bits, in this example, up to 16 different intervals are indicated. Here, a value of 0000 304 corresponds to a minimum interval of 100 milliseconds 306. Here, the maximum value shown of 1001 308 corresponds to a long interval of 1 second 310. FIG. 3B shows an exemplary MAC control element 320 consisting of a 4-bit interval indicator 322 and a 10-bit system frame number 324 used as an offset. The 10-bit system frame number can be made smaller by using a SFN offset from the current SFN instead of 0.

[0107] Different types of information may be given in a request for offset or offset change message. A request for an offset or offset change may include either the SFN and / or subframe offset of the SPS (i.e., the timing of one of the SPS resources), a required time shift of the SPS resource pattern relative to the current time pattern (positive or negative, potentially expressed in units of subframes such as frames, subframes, or scheduling periods), an index (potentially configured by the eNB or predefined) that identifies one of several possible timing offsets for the SPS resource pattern, and an identity of the SPS process whose timing needs to be changed (in case multiple are configured).

[0108] The SFN and / or subframe offset of the SPS, e.g., the timing of one of the SPS resources, may be represented by either the absolute SFN and subframe of the first SPS resource with the other resources separated by a configured SPS period, an offset from a predefined fixed subframe (e.g., SFN0 (mod x) and subframe 0), an offset from the start of the scheduling period associated with the sidelink resource pool, and / or an offset from the original transmission by the eNB of a PDCCH with an SPS C-RNTI, a PDCCH with DCI format 5, or any similar PDCCH message used by the eNB to initiate SPS resource allocation following its configuration.

[0109] For an index that potentially identifies one of several possible timing offsets for an eNB-configured or predefined SPS resource pattern, the eNB may send a set of indexed allowed offsets in the SPS configuration, and the WTRU may provide an offset change by providing an index corresponding to the desired offset.

[0110] With regard to identifying the SPS process (if multiple are configured) whose timing needs to be changed, such identification may be done by sending an index that references an index given by the eNB during the configuration of multiple SPSs. Such identification may also be done by sending an index that corresponds to the order of SPS grants for a particular frame / subframe combination (e.g., SFN x mod y, subframe 0).

[0111] Such information relating to an offset or a request for a change in offset is further referred to as offset change information.

[0112] The WTRU may send such a request for an offset or a change in offset using one or more of the following: The request for an offset may be provided in an RRC message containing offset change information, which may come following an RRC Radio Resource Configuration message that configures the SPS in the WTRU, or any time following the WTRU's attachment to the eNB. The request for an offset may be provided in a MAC Control Element (CE) message containing offset change information.

[0113] The request for the offset may be given in a BSR that contains offset modification information. In particular, the WTRU may trigger a BSR when it determines that the timing of the SPS allocation requires modification. The BSR may be a sidelink BSR in case the SPS resources and transmissions are on PC5 and not on the UL. The offset modification information may be included in the BSR or the sidelink BSR.

[0114] For example, the BSR or sidelink BSR may include in a new field the SFN and subframe, time shift, or SPS configuration index for the SPS configuration. Such information may be further associated with a logical channel group for which the WTRU may utilize the SPS configuration to transmit data. The information may be in the form of one or more additional fields for buffer sizes associated with the logical channel group.

[0115] The BSR or sidelink BSR may include the SFN, subframe, and time shift that may be sent instead of the buffer size for a particular logical channel group. The WTRU may utilize the special destination index field, the logical channel group, or a combination of the two to indicate that the corresponding buffer size field indicates SPS timing information instead.

[0116] The BSR or sidelink BSR may include a special flag indicating that a change in SPS timing is requested as a result of the transmission of the BSR. The requested new timing of the SPS configuration may be indicated by the time instance at which the WTRU sends the BSR. For example, the WTRU may indicate that the new offset or timing of the SPS corresponds to the number of subframes (possibly 0) following the subframe in which the BSR was transmitted.

[0117] The BSR or sidelink BSR may include an index associated with one of the predefined or allowable timing offsets for the SPS pattern.

[0118] The request for the offset may be given in a physical (PHY) layer message, such as, but not limited to, a scheduling request (SR), a physical uplink control channel (PUCCH), a sounding reference signal (SRS), or a random access procedure (RACH). For example, a special dedicated SR resource may be assigned to the WTRU for sending the desired SPS offset. If multiple SPS configurations exist, different SRs may be configured. The actual SFN and offset for the start of the SPS resource may be understood to occur a certain number of subframes, for example, following a subframe transmitted by the WTRU in the same subframe, or after a predefined number of subframes known by both the WTRU and the eNB.

[0119] The WTRU may send a requested offset message at any time during operation to change the offset of the current SPS resources. For example, the WTRU may send a requested offset message to the eNB as a result of one of the transitions shown in the timeline shown in Figure 2, where the offset may change between SPS and CAM but both intervals remain the same. More detailed triggers for the WTRU to send a requested offset message are further described below.

[0120] The WTRU receives a timing change confirmation from the eNB. In particular, following transmission of the requested offset message, the WTRU may receive a timing change confirmation confirmation from the eNB that may provide the new timing for the SPS configuration. Such a confirmation may be received using either a PDCCH message, a MAC CE message, or an RRC message.

[0121] For the PDCCH message, the timing change confirmation may be indicated using an SPS C-RNTI that identifies the SPS configuration as well as the new timing of the SPS resources. In case of multiple SPS configurations, each SPS configuration may be represented by a separate SPS C-RNTI.

[0122] 4 is a diagram of an example MAC header 402 and a MAC payload 404 comprising multiple MAC CE messages 406, 408. For one or more of the MAC CE messages 406, 408, a timing change confirmation may be indicated by a message including the new timing using, for example, the SFN and / or subframe offset and an identification of the SPS configuration indicated herein by the interval I2. A subframe number 412 may be included in the MAC CE. The MAC payload 404 may further comprise one or more MAC SDUs 414 and padding 416.

[0123] With respect to the RRC message, the timing change confirmation may be indicated by a message containing the new timing (SFN and / or subframe offset) and an identification of the SPS configuration.

[0124] The WTRU may apply / assume / infer new timing for the resources upon receipt of a timing change confirmation from the eNB. The WTRU may further assume that the new timing is given in the requested offset message (if the eNB does not provide the timing) or may assume that the new timing is the timing given in the timing change confirmation from the eNB.

[0125] The WTRU may receive a confirmation from the eNB using the PDCCH or MAC CE. In this case, the WTRU may assume that the existing RRC configuration of the SPS is maintained, and timing changes are simply applied using the information in the confirmation message. If the WTRU receives the confirmation using RRC, the confirmation may also provide a new configuration of the SPS. The WTRU may then update its RRC configuration with the configuration provided in the confirmation message.

[0126] For example, following transmission of a requested offset message, the WTRU may receive a corresponding PDCCH using the SPS C-RNTI to signal a change in SPS timing with the new offset. The WTRU may assume that the previous SPS timing of the resource (with the old offset) will persist until it receives a PDCCH with the SPS C-RNTI (which should occur at the offset it requested).

[0127] FIG. 5 illustrates an example of timing of messaging 500 by which a WTRU sends a requested offset or offset change for SPS. A vehicle or WTRU 502 may send an RRC connection request 506 to an eNB 502. The WTRU 502 may receive an RRC connection reconfiguration message 508 in response. The RRC connection reconfiguration message may include spsConfig. A Cam message may be initiated by an application layer 510. The WTRU 502 may send an offset request message 512. The WTRU may receive an SPS C-RNTI 514 on a PDCCH. The WTRU may start using SPS resources at the requested offset 516. If a change in offset 518 in the CAM message is determined by an application, etc., the WTRU 502 may send an offset-specific request message 520. Upon receiving a PDCCH with an SPS C-RNTI 522, the WTRU may start using SPS resources at the newly requested offset 524.

[0128] A trigger for the WTRU to send an offset or offset change to the eNB is provided. Based on any of the information provided by higher layers defined below (e.g., higher layer indication of timing of message arrival, indication of change in periodicity, indication of change in timing, message tagged by higher layers, information based on WTRU providing timing to higher layers, information regarding change in vehicle dynamics), the WTRU may determine the need to send an offset change to the eNB based on one or more of the following triggers:

[0129] The trigger may be when a timing change indication is received from a higher layer.

[0130] A trigger may, as the case may be, be indicated by the arrival of a message from higher layers related to a particular PPPP or QCI, or the timing of the arrival of a message on a particular radio bearer, logical channel, etc., satisfying one of the following conditions:

[0131] The trigger may be triggered when the time between receipt of the higher layer indication and the next subsequent scheduled SPS resource is greater than a certain threshold Ta or less than a certain threshold Tb, which may correspond to the processing latency expected by the AS, such that a time difference less than the threshold corresponds to having a processing latency required by the AS that exceeds this difference.

[0132] The trigger may be caused when the time difference between the current message arrival and the previous message arrival differs (e.g., by a configured amount) from the previous Na intervals of timing between message arrivals or differs (e.g., by a predefined, configured amount) from a determined periodicity of the messages (such periodicity may be provided by an application layer or determined by a lower layer in the WTRU).

[0133] The trigger may be caused when the timing of the message arrival is closer in time to another potential timing for the SPS resources (eg, configured by the eNB).

[0134] A trigger may be caused when the timing conditions described above occur a certain number of times (xNb) consecutively.

[0135] If the WTRU sends information about the desired offset or timing for the SPS, the WTRU may calculate this information based on one or more of the following:

[0136] The WTRU may select the timing offset to coincide with any subframe that is at least Tc milliseconds following the CAM message timing (where Tc may be 0).

[0137] The WTRU may select a timing offset to coincide with a subset of allowed subframes or allowed timings that are at least Td ms following the CAM message timing but that minimize the time difference between the SPS resources and the CAM message timing. The subset of allowed subframes may be configured by the eNB. For example, the subset of allowed subframes may consist of allowed D2D subframes for the sidelink defined by a TRPT or D2D subframe pattern for the WTRU defined by the eNB or defined by the WTRU's transmission pool on PC5. The WTRU may select one of the preconfigured timing offsets preconfigured by the eNB that minimizes the time difference between the SPS resources and the CAM message timing.

[0138] In another example, the WTRU may send an indication to the network (e.g., eNB) to change the period and / or scheduling interval of the SPS configuration. For example, the WTRU may send an indication to the eNB to request a change in the scheduling interval of the current SPS configuration. In particular, the WTRU may inform the eNB of the need to change the SPS configuration (e.g., scheduling interval and / or offset) upon a trigger from higher layers (e.g., detecting the need to change the CAM frequency due to a change in vehicle dynamics). The WTRU may assume that a change in the configuration may take effect as a result of this indication. Alternatively, the WTRU may receive a message from the eNB with the new SPS configuration or a message confirming the change in the configuration requested by the WTRU. The configuration change may then take effect (i.e., the WTRU starts using the new SPS configured resources) at any one of the following time instances: upon receipt of an indication by the eNB (e.g., based on the WTRU receiving an acknowledgment (ACK) from the eNB, e.g., via a Physical Hybrid ARQ Indicator Channel (PHICH)); at some future moment indicated by the WTRU; at some future moment that may be statically defined (i.e., in the WTRU specification) and relative to the last SPS resource allocation; at the time the eNB receives the indication (e.g., determined by the WTRU's transmit time and / or receipt of an ACK from the eNB via the PHICH); at the time the WTRU sends the indication to the eNB or at a moment explicitly given in the indication; upon receipt by the WTRU of the new SPS configuration by the eNB; and / or upon receipt by the WTRU of a confirmation that the indication was received by the eNB. Acknowledgement that the instruction was received by the eNB may be sent through one or more RRC messages, such as an SPS release followed by a new SPS configuration, a PDCCH grant using an SPS C-RNTI associated with the configuration, a PDCCH using a new C-RNTI or a new downlink control information (DCI) format, and / or a new MAC CE.

[0139] Based on any of the information provided by higher layers defined in Section 4.1.5, the WTRU may determine the need to send an instruction to change the SPS configuration. The instruction to the eNB to change the SPS configuration may be sent by the WTRU as a result of a trigger.

[0140] WTRU triggers for sending SPS configuration changes are provided. For example, based on any of the information provided by higher layers defined below (e.g., higher layer indication of timing of message arrival, indication of periodicity change, indication of timing change, messages tagged by higher layers, information based on WTRU providing timing to higher layers, information regarding changes in vehicle dynamics), the WTRU may determine the need to send an indication to change the SPS configuration based on any of the following triggers:

[0141] The trigger may be caused by a decision by the AS, the adaptation layer, described below, or the application layer that the period of the CAM message has changed. Such a decision, whether performed by the AS or by the adaptation layer, may follow the rules defined below for the adaptation layer to manage the SPS for CAM messages, described below, and may be based on information provided by higher layers.

[0142] The trigger may occur from the AS or from the V2X application layer running on the WTRU before, during, or following the generation of the CAM being sent with a CAM interval different from the previous interval.

[0143] The WTRU or the AS in the eNB itself may trigger an indication to the eNB when it determines that the CAM interval has changed (e.g., received a CAM message at an interval shorter than the previous interval, or did not receive a CAM message at the expected time for the last interval).

[0144] The number of upcoming intervals that the CAM interval is expected to remain the same (and its corresponding value) may trigger an indication to the eNB.

[0145] An indication that the CAM interval has been changed to its maximum value (1 sec) may trigger an indication to the eNB.

[0146] As part of the triggered instruction to the eNB, the WTRU may send one or more of the following information: a requested new scheduling interval for SPS configuration, a subframe (i.e., offset) in which the SPS resources with the new scheduling interval should start, a requested resource size for the SPS resources, an index identifying one of several possible timing offsets for the SPS resource pattern, and / or an identity of the SPS process whose timing needs to be changed (e.g., in case multiple processes are configured).

[0147] Regarding the new scheduling interval requested for SPS configuration, the WTRU may give the eNB one of the possible SPS periodicities initially configured by the eNB. Alternatively, the WTRU may give the eNB any periodicity supported for SPS (predefined or standardized).

[0148] For an index that identifies one of several possible timing offsets for an SPS resource pattern (potentially configured by the eNB or predefined), the eNB may send a set of allowed offsets with indexes in the SPS configuration, and the WTRU may provide an offset change by providing an index corresponding to the desired offset.

[0149] With regard to identifying the SPS process whose timing needs to be changed (e.g., when multiple are configured), such identification may be done by sending an index that references an index given by the eNB during the configuration of multiple SPS. Alternatively, such identification may be done by sending an index that corresponds to the order of SPS grants for a particular frame / subframe combination (e.g., SFN x mod y, subframe 0).

[0150] The indication may be sent by the WTRU to the eNB using one of the following methods: a new MAC CE, a new special BSR that may hold the information given above, an SR potentially sent on predefined resources to notify the eNB of this event followed by transmission of the above information using a BSR or MAC CE, a PUCCH potentially sent on predefined resources to notify the eNB of this event, a new MAC CE sent in the SPS resources itself, a RACH or similar transmission by the WTRU performed on the next available RACH resource, or an RRC message.

[0151] Following sending the indication to the eNB, the WTRU may continue to use the existing SPS configuration for CAM transmission until it receives a confirmation from the eNB. Alternatively, if no confirmation is expected, the WTRU may change the SPS resources to use for CAM transmission to the new configuration at any of the start time instances described above (i.e., the SPS changes implicitly based on sending the indication).

[0152] Figure 6 is a messaging flow diagram for an example embodiment. In Figure 6, the WTRU access layer may receive a message from the application layer upon the occurrence of any of the trigger conditions (1) or (2) described below 602. According to condition (1), the time elapsed since the last CAM generation is equal to or greater than T_GenCam_Dcc, and one of the following ITS-S dynamics related conditions is given: the absolute difference between the originating ITS-S's current heading direction and the heading direction included in the CAM previously sent by the originating ITS-S is greater than 4°, the distance between the originating ITS-S's current location and the location included in the CAM previously sent by the originating ITS-S is greater than 4m, or the absolute difference between the originating ITS-S's current speed and the speed included in the CAM previously sent by the originating ITS-S is greater than 0.5m / s. Here, T_GenCam_Dcc provides a minimum time interval between two consecutive CAM generation to reduce CAM generation according to the channel usage requirement of Decentralized Congestion Control (DCC). According to condition (2), the time elapsed since the last CAM generation is greater than or equal to T_GenCam and greater than or equal to T_GenCam_Dcc, where T_GenCam represents the currently valid upper bound on the CAM generation interval.

[0153] A trigger from an application or entity managing the dynamics of a vehicle that changes speed, direction, or position from a state in which trigger condition (1) above is valid to a state in which condition (1) is not valid.

[0154] Upon determining that the SPS interval needs to be changed from interval I1 to interval I2 (e.g., upon receiving a message from the application layer when either of trigger conditions (1) or (2) occurs), the WTRU access stratum may send a MAC CE 604 to the eNB containing I2 as well as the subframes in which the RAN expects to be able to send the next CAM message (i.e., new offset timing). The WTRU may then be scheduled with the dynamically scheduled resources or may send an SR to trigger the scheduling of such dynamic resources and may send any pending CAM messages using the dynamically scheduled resources. At some time following the indication using the MAC CE, the WTRU access stratum may be scheduled on the PDCCH using the SPS C-RNTI. Upon receipt of this scheduling on the PDCCH, the WTRU may assume that the SPS configuration will be changed and that the scheduling interval will be I2 for this SPS. The WTRU may also modify the corresponding components in the RRC accordingly.

[0155] FIG. 7 illustrates an example embodiment that may reduce the time required for an eNB to signal an SPS change. The WTRU access stratum may receive a message from the application layer when a triggering condition occurs, e.g., when any of the conditions (1) or (2) described above occur 702. Upon determining that the SPS interval should be changed from interval I1 to interval I2 704, the WTRU access stratum may send a new special BSR containing interval I2 and the subframe in which the access stratum expects to be able to send the next CAM message (i.e., new offset timing) 706. Upon receipt of an ACK associated with the MAC protocol data unit (PDU) in which the special BSR is sent, the WTRU may assume that it has changed its SPS configuration according to the request. The WTRU may also change the corresponding components in the RRC accordingly.

[0156] In another example embodiment, the WTRU access stratum may receive a message from the application layer or higher layers indicating that the periodicity of the CAM messages has been changed, for example, from 1 second to 200 ms. Upon receiving this information, the WTRU access stratum may send a MAC CE containing an identity of the SPS configuration whose duration is to be changed, as well as the new required duration for the SPS configuration. The WTRU may continue to assume the current configuration of SPS until it receives a new SPS configuration from the eNB (e.g., via RRC messaging). Upon receiving the new SPS configuration, the WTRU may cancel the current SPS configuration and activate the new SPS configuration only after receiving a PDCCH message encoded with the SPS C-RNTI (e.g., DCI format 5 for sidelink) associated with the new SPS configuration.

[0157] The WTRU may also send an indication, message and / or notification to release certain resources (e.g., a subset of SPS resources). For example, the WTRU may send a message to the eNB to release a specific set of SPS resources associated with an SPS configuration, but not release the entire configuration. For example, the WTRU may indicate that it does not need (does not intend to use) SPS resources associated with the next X SPS scheduling intervals. This will allow the eNB to schedule these resources to other WTRUs. After the X scheduling intervals, the WTRU may then assume that it again has access to the SPS resources according to the existing SPS configuration.

[0158] The WTRU may send an indication to release certain resources using one of the following methods: a new MAC CE, a new special BSR that may hold the information given above, an SR potentially sent on predefined resources to notify the eNB of this event followed by transmission of the above information using the BSR or MAC CE, a PUCCH potentially sent on predefined resources to notify the eNB of this event, a new MAC CE sent in the SPS resources itself, a RACH or similar transmission by the WTRU performed on the next available RACH resource, or an RRC message.

[0159] Multiple SPS configurations are provided. In particular, multiple SPS configurations and activation / deactivation of configurations are provided, which may be dynamically performed in real time according to conditions and trigger events. For example, a WTRU may be configured with multiple SPS configurations, but may have only one configuration active at a given time. The WTRU may then request to change (cycle) between one configuration and one or more other configurations by deactivating a currently active configuration and activating another configuration.

[0160] The WTRU may receive multiple configurations from the eNB along with an RRC connection reconfiguration message. The WTRU may receive an active configuration of the given configurations from the eNB. Alternatively, the WTRU may assume that none of the configurations are active and instead need to indicate to the eNB later which configuration to activate. The WTRU may send identifiers associated with the SPS configurations in an SPS activation / deactivation message to the eNB to activate or deactivate the corresponding SPS configuration.

[0161] The WTRU may send the configuration activation / deactivation message or indicator using one of the following methods: a new MAC CE, a new special BSR indicating the configuration to activate / deactivate, an SR potentially sent on predefined resources to notify the eNB of this event, a PUCCH potentially sent on predefined resources to notify the eNB of this event, a RACH or similar transmission by the WTRU performed on the next available RACH resource, an RRC message, or an SRS-like message, where the location of the SRS resource may also potentially indicate the SPS configuration to activate or deactivate. Additionally, the location of the SR may also indicate which SPS configuration to activate / deactivate.

[0162] The WTRU may consider the requested configuration to be activated upon transmission of an activation / deactivation message. Alternatively, the WTRU may consider the requested configuration to be activated upon acknowledgment by the eNB either through a MAC CE such as a PDCCH message (e.g., PDCCH with SPS C-RNTI), an explicit RRC message, or a Hybrid Automatic Repeat Request (HARQ) ACK to a MAC PDU carrying a PHY layer message.

[0163] In one embodiment, the WTRU may send a new MAC CE to activate one SPS configuration while deactivating the other configuration. The activation may take effect in the subframe in which the WTRU receives the SPS C-RNTI from the eNB.

[0164] The WTRU may potentially use the above mechanisms to disable all SPS configurations based on a trigger from higher layers, for example, the WTRU may receive an indication (e.g., from an adaptation layer) not to use SPS.

[0165] Triggers for requesting a change in the SPS configuration include an application layer, adaptation layer, or higher layer indicating when it has changed the period of traffic (e.g., from 1 second to 100 ms, or vice versa); an application layer, adaptation layer, or higher layer indicating that it has changed the timing (offset), what the new offset is, and that it has changed the timing by a certain amount (e.g., greater than a threshold); and the WTRU determining that one configuration may be better than another configuration based on the information provided by the application layer, adaptation layer, or higher layer.

[0166] FIG. 8 illustrates some application level trigger events for V2X communications. For example, a change in autonomous mode may be detected when the vehicle switches from a human driver to electronic driving control 802. It may be desirable for the WTRU to be assigned a longer (or shorter) SPS periodicity so that the autonomous vehicle may be assigned more system bandwidth to transmit / receive information accordingly. The same may be true in the case of an instruction 804 of a driver under 18 years of age. Another exemplary trigger event is a change in system capabilities, which may relate to the software of the vehicle or firmware upgrades of the WTRU. In some cases, software updates may be frequent. The addition of new software or applications may also result in a change in system capabilities.

[0167] A prioritization of logical channels that applies to SPS grants is provided. In particular, when a WTRU transmits using a grant associated with a given SPS configuration, it may select data from the logical channels to be transmitted using that grant. The selection from the logical channels of data to be transmitted may be based on using a combination of criteria that may be prioritized in any order: transmitting data with the highest priority based on PPPP, transmitting data with decreasing priority of PPPP, transmitting data whose periodicity matches or is smaller than or larger than the periodicity of the SPS configuration associated with the grant, transmitting data whose size matches or is smaller than or larger than the grant size of the SPS configuration associated with the grant, transmitting data based on a configured mapping between higher layer data / services or logical channels and SPS configurations, delaying transmission of data until a grant for the associated SPS configuration is received, and the amount of time until the next grant associated with a particular SPS configuration. Such a selection may apply whether the WTRU has multiple SPS configurations active simultaneously or a single active SPS configuration.

[0168] In one example, the WTRU may select SPS resources to utilize for transmission of data coming from higher layers based on an SPS configuration from the eNB. The WTRU may receive an SPS configuration associated with one or more logical channels, logical channel groups, radio bearers, PPPP, QCI, etc.

[0169] The WTRU may only transmit data from one or more logical channels, etc., using an SPS grant for the SPS configuration associated with the logical channels.

[0170] Alternatively, the WTRU may first transmit all data from the associated logical channel and then transmit any remaining data (potentially from other logical channels not associated with the SPS configuration) if a grant allows for the transmission of additional data, but all data in the buffer for the associated logical channel may be transmitted using the grant.

[0171] Furthermore, the WTRU may first transmit all data with a higher priority (e.g., PPPP, or logical channel group (LCG) priority (i.e., LCP)) than the configured logical channel associated with the SPS configuration before transmitting any data from the configured logical channel. Alternatively, the WTRU may first consider all data associated with the SPS configuration before considering data with a higher priority (e.g., PPPP or LCG priority).

[0172] In another example, the WTRU may determine which SPS resource to utilize based on the configured periodicity and / or allocation size of the SPS resource and information from the application layer. In this case, the WTRU may determine the required transmission interval for a particular application layer packet based on the application layer information included with the packet. Such information may be in the form of a QCI-like parameter indicating the periodicity or timing requirement attached to the packet. It may also be provided to the WTRU in the form of a PPPP, where a particular PPPP may be used to indicate data (e.g., CAM traffic) with a particular transmission period.

[0173] When selecting data to be transmitted on an SPS resource, the WTRU may identify a periodicity associated with an SPS configuration associated with a particular SPS resource, select an upper layer PDU that requires a matching periodicity for multiplexing into a MAC PDU for transmission, and if all data from the matching periodicity is included, select an upper layer PDU that requires a shorter periodicity for multiplexing into a MAC PDU for transmission, and if all of the above are included, select an upper layer PDU for any periodicity or select an upper layer PDU that is not associated with any particular periodicity or timing requirement for multiplexing into a MAC PDU for transmission.

[0174] In another example, the WTRU may postpone selection of an RLC PDU for transmission until occurrence of a grant from an associated SPS configuration (based on a configured or WTRU-determined mapping) and select the PDU only when the grant is received. In this case, the WTRU may avoid selecting an RLC PDU from a logical channel (regardless of its priority) when selecting an RLC PDU for transmission of a MAC PDU, and select an RLC PDU from the next highest logical channel (by priority) for transmission. The WTRU may further avoid selecting a PDU under a condition where the time of arrival of the next grant for the associated SPS configuration is shorter than some preconfigured threshold. Otherwise, the WTRU may be configured to transmit the packet using a legacy mechanism (e.g., using a current grant via the legacy mechanism to request a grant).

[0175] Managing concurrent SPS grants is provided. In particular, the WTRU may be configured with multiple active SPS configurations such that grants from different SPS configurations occur simultaneously. This may consist of grants occurring on the same UL subframe (for UL SPS transmissions) or grants occurring on the same scheduling period (e.g., for sidelink (SL) SPS transmissions). SL SPS refers to SPS configured for device-to-device (D2D) communications.

[0176] In one example, a WTRU configured with concurrent SPS grants may be required or expected to transmit using only one of the grants. This may be, for example, when the eNB assumes that the WTRU will use only one of the configured grants and allocate UL resources to other WTRUs. The grant to be used by the WTRU may be selected according to any of the following criteria:

[0177] For example, the grant with the largest allocated resources in terms of resource blocks may be selected. The grant whose allocated resource size is closest to the size of the data to be transmitted by the WTRU, e.g., transmitted in a BSR for the WTRU, may be selected. Potentially, in this scenario, the grant should also be equal to or greater than the amount of data to be transmitted by the WTRU or indicated by the WTRU in the BSR. The grant with the best channel properties (e.g., based on measurements made by the WTRU or by the eNB) may be selected. For example, the grant with the least interference from other transmitting WTRUs detected by the WTRU through sensing or with the least overlap (in terms of resources) with transmission resources selected by another WTRU during the same scheduling period may be selected.

[0178] In this example, the WTRU may further use the rules for logical channel prioritization (LCP) described above to select data to transmit for the configured and selected grant.

[0179] In another example, a WTRU configured with concurrent SPS grants may be required or expected to transmit for all of the grants during a given scheduling period or UL subframe. In this case, the WTRU may further use the rules for LCP described above to select data to transmit for the concurrent grants. The WTRU may also perform LCP in this case while following any of the following rules:

[0180] For example, the WTRU may consider the sum of the grant sizes of the concurrent grants as the available grant size for transmission of the MAC PDU and perform the LCP given the sum of the grant sizes. Additionally or alternatively, the WTRU may select a grant to use to transmit the RLC PDU such that the RLC PDU does not need to be segmented. Additionally or alternatively, the WTRU may consider each grant separately and apply the above rules to the LCP. For example, the WTRU may select only RLC SDUs from logical channels associated with the SPS configuration for transmission in the configured SPS grant.

[0181] The WTRU may indicate when to not use a particular grant so that the eNB may reallocate in the context of multiple configured SPS grants. For example, when the WTRU is configured with multiple grants and uses only a subset (e.g., one) of the configured SPS grants in a particular subframe, the WTRU may be configured to indicate to the eNB which grants it will not use so that the eNB may reallocate resources to another device. In one example, the WTRU may first determine which grants it will be using and then signal (e.g., via an index) to the eNB (e.g., using a physical channel or other channel) which SPS grants it will be using. The eNB may determine from this information which SPS grants are not used so that the eNB may allocate resources to another device. This approach is advantageous when multiple SPS grants are configured and the WTRU uses only one of the SPS grants. In another example, a WTRU may be configured with two SPS grants, and the WTRU may indicate the SPS grant index of the SPS grant it does not intend to use (e.g., a canceled SPS grant). To be effective, the indication may need to be sent a certain time before the actual SPS grant is made.

[0182] Higher layer assistance is provided to trigger SPS scheduling assistance. For example, as already mentioned above, the WTRU may receive information from higher layers (e.g., higher layer indication of timing of message arrival, indication of periodicity change, indication of timing change, messages tagged by higher layers, information based on which the WTRU provides timing to higher layers, and information regarding changes in vehicle dynamics). The WTRU may determine the need to send an offset or periodicity change to the eNB based on information from higher layers. This may correspond to information from an application layer or information from an adaptation layer, the embodiments of which are described below.

[0183] Information received from higher layers is further described. The higher layer information may include a higher layer indication of the timing of arrival of a message. For example, the WTRU may receive an indication of arrival of a CAM message from an application layer or higher layer. Such an indication may be received each time the higher layer sends such a message to the AS.

[0184] The higher layer information may include an indication of a change in periodicity. For example, the WTRU may receive an indication of a change in periodicity or interval for the CAM messages as well as a new duration for the CAM messages from an application layer or higher layer.

[0185] The higher layer information may include an indication of a change in timing. For example, the WTRU may receive an indication from an application layer or higher layer that a change has been made in the timing of a CAM message (or a message requesting SPS alignment) determined by the higher layer. The indication may further include an absolute time of the new timing of the message to be sent to the lower layer (e.g., the time of transmission of one instance of a periodic message stream). Alternatively, the indication may be sent to coincide with the transmission of the message with the new timing (e.g., the timing of the indication represents the timing of the message).

[0186] The upper layer information may include messages tagged by the upper layer. For example, a CAM message or a message requesting SPS alignment may be tagged or indicated as such by the upper layer. For example, the message may be tagged with a particular Packet Data Convergence Protocol (PDCP) Service Data Unit (SDU) type that identifies the message as a message requesting SPS alignment. The message may include a particular value of per packet priority (PPPP) indicating that this message requests SPS alignment. Additionally, the message may be received with other QoS related information, such as a QCI or similar information, where a particular value of QCI may indicate the need for SPS alignment, and / or timing related requirements, e.g., a latency requirement of 100 ms and / or a particular value of packet delay budget (PDB) representing periodic data.

[0187] The WTRU may be further configured by the eNB such that all traffic or messages requiring alignment with an SPS are assigned to a particular logical channel, radio bearer, etc. Such restrictions may be based on application layer information such as QCI or PPPP. For example, the WTRU may assign all messages a particular PPPP or QCI indicating the need for alignment of the SPS to a particular logical channel.

[0188] The upper layer information may include information based on the WTRU providing timing to the upper layer. For example, the WTRU may provide the configured timing of the SPS to the upper layer, potentially upon configuration of the SPS by the eNB, either in the form that the WTRU may provide the upper layer or the application layer with an absolute time instance of the occurrence of one of the SPS resources, and / or in the form that the WTRU may provide an indication or signal to the AS of the presence of such resources for some or each occurrence of the SPS resource. The application layer may further provide an indication to the lower layer that a change is needed to the currently configured SPS timing and additional information (e.g., a time shift of the SPS resource or resource pattern required to satisfy the generation of the current application layer message) is needed to create an offset change message to the eNB.

[0189] The higher layer information may include information related to a change in vehicle dynamics. For example, the AS may receive information related to a change in vehicle dynamics, such as an indication of a change in speed, heading, or acceleration above a threshold that triggers an event defined in conditions (1) and (2) described herein, an indication that either of trigger conditions (1) or (2) described above occurs, and / or an indication that the speed, heading, or position has changed from a state in which trigger condition (1) is valid to a state in which it is not valid.

[0190] As explained above, the CAM size may change periodically depending on whether the V2X application wants to transmit frequent, infrequent, or other special containers. Therefore, a fixed SPS allocation is not ideal to provide the necessary resources to transmit the CAM. Furthermore, the eNB needs to be aware of the SPS allocation size required for the CAM message, but this information only exists in the WTRU (e.g., in the vehicle).

[0191] Thus, the SPS message size may be configured through the application layer. For example, the V2X application of the WRTU may provide size information to a corresponding application in the network or at the eNB through application layer signaling, e.g., as a CA Basic Service message. The size information that may be sent through the application layer message may include the container size, the pattern in which frequent, infrequent, or special containers are sent, and / or any dynamic changes in the pattern that occur during operation, e.g., when the V2X WTRU decides to send infrequent containers more frequently than required.

[0192] The application layer at the network or eNB may provide this information to the eNB to define the appropriate SPS allocation size and may provide any additional dynamic scheduling for time instances where the allocated SPS size needs to be increased, e.g., additional containers may be included in the CAM messaging.

[0193] In another example, the SPS message size may be associated with a Quality of Service (QoS) Class Identifier (QCI) for the logical channel. For example, the required SPS allocation size and potentially the pattern of CAM message size changes are related to the QCI associated with the V2X logical channel. Once the V2X logical channel is established, the eNB may know or determine (e.g., based on a predefined mapping or from information obtained from a V2X application service in the network) the size of the SPS allocation required to be able to hold the CAM message.

[0194] The WTRU may send a synchronization message to the eNB to indicate the timing and frequency of transmission of frequent and infrequent containers, so the WTRU may know or determine the time instances when the SPS allocation needs to be increased or overridden by dynamic allocation. For example, the message may indicate the SFN and subframe corresponding to the transmission of an infrequent container, which is transmitted every X CAM messages.

[0195] In another example, the change in allocation size may be piggybacked on the SPS transmission. For example, the WTRU may send a message indicating that the next upcoming CAM message has an increased size (e.g., that it will contain an infrequent container) and potentially also the size increment compared to the current SPS allocation. Such a message may be piggybacked as a MAC CE during the transmission of the current CAM message. The advantage of this solution compared to dynamic scheduling is that the WTRU does not need to send a separate SR or BSR when a larger CAM message arrives, thus avoiding the additional delay (and also additional signaling) associated with the SR / BSR method.

[0196] In another example, the SPS allocation size may be increased periodically. For example, the WTRU may be configured with an SPS allocation that is increased periodically beyond the resource allocation specified in the PDCCH with the SPS C-RNTI. The increase in resource allocation may be fixed (e.g., always twice the SPS allocation) or may be determined by the WTRU from signaling received from the eNB. For example, the SPS configuration in the RRC signaling itself may include details of the increase in resource allocation for SPS, how frequently it occurs, and the relationship of the additional resource elements to the normal SPS allocation. In another example, the PDCCH with the SPS C-RNTI itself, potentially using a new DCI, may indicate the amount of increase in SPS allocation and how frequently this occurs, along with the actual time-frequency location of the increased allocation.

[0197] An adaptation layer is provided to manage the SPS for CAM messages. The V2X application, which manages the structure and transmission of CAM messages (and other V2X messages such as Basic Safety Messages (BSM) or Decentralized Environmental Notification Messages (DENM)), may interface with different types of carriers such as LTE (e.g., sidelink and Uu) and dedicated short range communications (DSRC). Since latency requirements need to be met regardless of the carrier utilized, it may be best from an implementation perspective to build an adaptation layer that allows the V2X application to interface with a particular carrier while meeting the latency requirements of the V2X messages without the need to add transport layer specific information in the V2X application itself.

[0198] An adaptation layer for V2X to LTE may provide functionality for SPS, enabling / disabling SPS based on whether the vehicle dynamics justify its use, as well as providing information to the AS to determine the duration and timing of SPS traffic. Note that the functionality described for the adaptation layer may also be within the AS or application layer depending on the particular implementation of the WTRU or application layer resident on the WTRU.

[0199] With regard to enabling / disabling SPS for CAM traffic, the adaptation layer may send an indication to lower layers to indicate when it may be advantageous to configure SPS (e.g., when the CAM traffic is relatively periodic). The WTRU may further send this indication to the eNB to enable / disable use of SPS (as described above).

[0200] The adaptation layer may make the decision to use SPS (i.e., enable / disable it) based on the vehicle's dynamics or other information provided by the application layer, such as whether the vehicle's speed is above a certain threshold (indicative of driving on a highway), the vehicle's proximity to other vehicles moving in the same or opposite direction, the vehicle's Global Positioning System (GPS) information, the type of road on which the WTRU is traveling, and / or traffic information such as the number of vehicles in the area around the vehicle or in the direction of the vehicle's movement.

[0201] Based on the above information, the adaptation layer may determine the level of periodicity of the CAM messages generated by the V2X application layer and may send an indication to lower layers in the WTRU as to whether to configure SPS.

[0202] In another example, the adaptation layer may instruct a similar adaptation layer residing in the network in making the same decisions defined above, and such an adaptation layer in the network may provide this information (e.g., for a particular WTRU) directly to the eNB.

[0203] To determine the SPS periodicity, the LTE adaptation layer may receive an instantaneous vehicle speed from the application layer. Such speed may be provided periodically to the adaptation layer. Alternatively, the LTE adaptation layer may receive a new speed or a trigger when a speed change above a certain threshold occurs. The adaptation layer may determine the required SPS periodicity and inform the AS layer of the required periodicity based on a simple lookup table. For example, the periodicity of x1 may be configured when the speed ranges from y11 to y12, the periodicity of x2 may be configured when the speed ranges from y21 to y22, and so on.

[0204] To determine the SPS timing, the LTE adaptation layer may receive from the application layer triggers corresponding to the CAM generation described above (i.e., trigger conditions (1) and (2)), i.e., absolute difference in heading exceeds a threshold (e.g., 4 degrees), distance exceeds a threshold (e.g., 4 m), and / or change in speed exceeds a threshold (e.g., 0.5 m / s). Such triggers may be received from the application layer using separate signaling (e.g., side information) or may be included in the CAM message itself.

[0205] The LTE adaptation layer may comprise frame and subframe timing based on either a signal or event sent by the AS for each subframe or interval or subframe, a frame and subframe counter maintained by the AS and readable / accessible by the LTE adaptation layer, and / or a function provided by the AS that converts absolute time (maintained in the WTRU) to frame and subframe time. The LTE adaptation layer may maintain precise timing related to the current SPS configuration based on its prior enabling of SPS in the AS. The precise timing may be maintained based on absolute time or based on frame / subframe timing. Alternatively, the LTE adaptation layer may receive from the AS the absolute time of the currently configured SPS configuration (e.g., configured by the eNB) and the currently configured periodicity. Based on this information, the LTE adaptation layer may be able to calculate the timing of each SPS resource in time.

[0206] Compensation for AS delay is provided. For example, the adaptation layer may provide the desired timing of the SPS to the AS. Such timing may include compensation for the delay of the AS (e.g., from the time the CAM message is generated to the time it is ready for over-the-air transmission). This compensation factor may be dynamically provided by the AS. This compensation factor may be determined by the LTE adaptation layer by using a static value related to the required delay. For example, assuming a maximum delay of 100 ms, the LTE adaptation layer may be configured with a compensation factor of 10 ms to account for the AS delay. This compensation factor may be determined by the LTE adaptation layer based on the capabilities of the WTRU, the network, etc., which may be provided in a subscriber identity module (SIM) card, during storage / configuration of the WTRU, provided by the AS following network attachment, and / or provided by the network as part of application layer or NAS layer signaling.

[0207] Although the features and elements are described above in certain combinations, one skilled in the art will appreciate that each feature or element may be used alone or in any combination with other features and elements. Furthermore, the methods described herein may be implemented in a computer program, software, or firmware embodied in a computer-readable medium for execution by a computer or processor. Examples of computer-readable media include electronic signals (transmitted over wired or wireless connections) and computer-readable storage media. Examples of computer-readable storage media include, but are not limited to, read-only memory (ROM), random access memory (RAM), registers, cache memory, semiconductor memory devices, magnetic media such as internal hard disks and removable disks, magneto-optical media, and optical media such as CD-ROM disks and digital versatile disks (DVDs). A processor in association with software may be used to implement a radio frequency transceiver for use in a WTRU, UE, terminal, base station, RNC, or any host computer.

Claims

1. 1. A method performed by a wireless transmit / receive unit (WTRU), comprising: receiving semi-persistent scheduling (SPS) configuration information, the SPS configuration information indicating a first identifier associated with a first SPS configuration and a plurality of resources associated with the first SPS configuration; determining not to use at least one resource of the plurality of resources associated with the first SPS configuration; sending a message to a base station, the message including an indication that the WTRU has determined not to use the at least one resource of the plurality of resources associated with the first SPS configuration; 23. A method comprising:

2. 2. The method of claim 1, wherein transmitting the message to the base station includes transmitting a medium access control (MAC) control element (CE) utilizing one or more resources associated with the first SPS configuration.

3. The method of claim 1 , wherein the SPS configuration information comprises a plurality of SPS configurations, each of the plurality of SPS configurations being associated with a respective plurality of resources.

4. 4. The method of claim 3, wherein a single SPS configuration of the multiple SPS configurations is active at a given time.

5. 10. The method of claim 1, wherein the SPS configuration information is received in a Radio Resource Control (RRC) connection message from the base station.

6. 2. The method of claim 1, wherein the message includes an indication that the WTRU has determined not to use a plurality of resources of the plurality of resources associated with the first SPS configuration.

7. The method of claim 1 , wherein the message is transmitted using one of the resources of the plurality of resources associated with the first SPS configuration.

8. 1. A wireless transmit / receive unit (WTRU), comprising: receiving semi-persistent scheduling (SPS) configuration information, the SPS configuration information indicating a first identifier associated with a first SPS configuration and a plurality of resources associated with the first SPS configuration; determining not to use at least one resource of the plurality of resources associated with the first SPS configuration; sending a message to a base station, the message including an indication that the WTRU has determined not to use the at least one resource of the plurality of resources associated with the first SPS configuration; Processor configured to A WTRU comprising:

9. 10. The WTRU of claim 8, wherein the processor configured to transmit the message to the base station comprises the processor configured to transmit a medium access control (MAC) control element (CE) utilizing one or more resources associated with the first SPS configuration.

10. 10. The WTRU of claim 8, wherein the SPS configuration information comprises a plurality of SPS configurations, each of the plurality of SPS configurations being associated with a respective plurality of resources.

11. 11. The WTRU of claim 10, wherein a single SPS configuration of the multiple SPS configurations is active at a given time.

12. 10. The WTRU of claim 8, wherein the processor is configured to receive the SPS configuration information in a radio resource control (RRC) connection message from the base station.

13. 10. The WTRU of claim 8, wherein the processor is configured to determine not to use a plurality of resources from the plurality of resources associated with the first SPS configuration, and the message includes an indication that the WTRU has determined not to use the plurality of resources from the plurality of resources associated with the first SPS configuration.

14. 10. The WTRU of claim 8, wherein the processor is configured to transmit the message using one of the resources of the plurality of resources associated with the first SPS configuration.

15. A base station, transmitting semi-persistent scheduling (SPS) configuration information to a wireless transmit / receive unit (WTRU), the SPS configuration information indicating a first identifier associated with a first SPS configuration and a plurality of resources associated with the first SPS configuration; receiving a message from the WTRU, the message including an indication that the WTRU has determined not to use at least one resource of the plurality of resources associated with the first SPS configuration; Processor configured to A base station comprising:

16. 16. The base station of claim 15, wherein the processor configured to receive the message from the WTRU comprises the processor configured to receive a medium access control (MAC) control element (CE) utilizing one or more resources associated with the first SPS configuration.

17. 16. The base station of claim 15, wherein the SPS configuration information includes a plurality of SPS configurations, each of the plurality of SPS configurations being associated with a respective plurality of resources.

18. 16. The base station of claim 15, wherein the processor is configured to transmit the SPS configuration information to the WTRU in a Radio Resource Control (RRC) connection message.

19. 16. The base station of claim 15, wherein the processor is configured to receive the message utilizing one of the resources of the plurality of resources associated with the first SPS configuration.

Citation Information

Patent Citations

  • Method and apparatus for supporting communication via relay nodes

    JP2013524643A

  • Efficient periodic scheduling for wireless communications - Patents.com

    JP2019509665A

  • Wireless terminal and base station

    WO2013038525A1

  • Radio terminal, radio base station, radio communication system, and radio communication method

    WO2014097357A1