Scheduling method and system for uu-based vehicle-to-vehicle communication

Abstract

A method for operating in a WTRU can include transmitting, from the WTRU to an eNB, a request for SPS resources, wherein the request includes a periodicity of the SPS resources requested and a time offset indicating a time at which the WTRU expects to be allocated SPS resources. The method can further include receiving, by the WTRU from the eNB, an SPS configuration in response to the transmitted request for SPS resources. The time offset of the transmitted request can include a subframe number (SFN) offset relative to SFN 0 of the WTRU. The received SPS configuration can correspond to a PC5 interface, and the SPS configuration can be received over a physical downlink control channel (PDCCH).

Description

[0001] This application is a divisional application of Chinese Patent Application No. 201780021656.3, filed on March 23, 2017, entitled "Scheduling Method and System for Vehicle-to-Vehicle Communication Based on Uu", the contents of which are incorporated herein by reference.

[0002] Cross-reference to related applications

[0003] This application claims the benefit of U.S. Provisional Application Serial No. 62 / 315,262, filed March 30, 2016, and U.S. Provisional Application Serial No. 62 / 366,152, filed July 25, 2016, the contents of which are incorporated herein by reference. Background Technology

[0004] 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 that use vehicles and roadside units as communication nodes in a communication network. These nodes provide each other with information, such as safety warnings and traffic information. In collaborative approaches, vehicle communication systems are more effective at avoiding accidents and traffic congestion than each vehicle attempting to solve problems individually.

[0005] Direct device-to-device (D2D) communications have begun to receive support from major standardization bodies such as the Institute of Electrical and Electronics Engineers (IEEE) or the 3rd Generation Partnership Project (3GPP). Regarding radio access based on 3GPP and Long Term Evolution (LTE), support for D2D communications is being introduced to allow the use of LTE technology to implement cost-effective, high-performance public safety communications. This is driven primarily by the desire to coordinate radio access technologies across jurisdictions to reduce the capital expenditure (CAPEX) and operating expenses (OPEX) of radio access technologies available for public safety (PS) type applications. Secondly, it is also driven by the fact that LTE, as a scalable broadband radio solution, allows for the efficient multiplexing of different service types, such as voice and video.

[0006] Because PS applications often require radio communication in areas not typically covered by LTE networks (such as in tunnels, deep basements, or after a catastrophic system outage), it is necessary to support D2D communication for PS in the absence of any operational network or before the arrival of the radio infrastructure deployed in AdHoc. However, even when operating with operational network infrastructure, PS communication typically still requires higher reliability compared to commercial services.

[0007] In addition to potential enhancements to LTE in both D2D and non-D2D aspects, V2X communication standards and technologies can be developed based on the current D2D LTE specifications to meet the requirements of the Services and Systems (SA1) subgroup of the 3GPP Technical Specification Group. Summary of the Invention

[0008] The present invention provides a method, apparatus, and system for aligning the generation and transmission of Cooperation Aware Messages (CAMs) with SPS resource timing based on a semi-persistent scheduling (SPS) configuration. The method includes transmitting an instruction to a node B to change the SPS configuration based on a triggering event, wherein the instruction to change the SPS configuration includes a request to change at least one of a scheduling interval and a current SPS configuration offset; reconfiguring the current SPS configuration based on the instruction to change the SPS configuration; and transmitting the CAM using SPS resources according to the changed SPS configuration.

[0009] An operational method in a Wireless Transmit / Receive Unit (WTRU) may include: transmitting a Semi-Persistent Scheduling (SPS) resource request from the WTRU to an Evolved Node B (eNB), the request including the periodicity of the requested SPS resource and a time offset, the time offset indicating the time at which the WTRU expects to allocate the SPS resource. The method may further include: in response to the transmitted SPS resource request, the WTRU receiving an SPS configuration from the eNB. The time offset of the transmitted request may include an SFN offset relative to the WTRU's subframe number (SFN) 0. The received SPS configuration may correspond to a PC5 interface. The SPS configuration may be received via a Physical Downlink Control Channel (PDCCH). Attached Figure Description

[0010] A more detailed understanding can be obtained from the following description, illustrated with the accompanying diagram, in which:

[0011] Figure 1A It is a system diagram illustrating an exemplary communication system that can implement one or more of the disclosed embodiments;

[0012] Figure 1B It is possible Figure 1A The system diagram shown illustrates an example wireless transmit / receive unit (WTRU) used internally within a communication system.

[0013] Figure 1C It is possible Figure 1A The diagram shows an example radio access network and an example core network used within the communication system.

[0014] Figure 2 This is a diagram illustrating the timeline of CAM timing.

[0015] Figure 3A This is an illustration of a 4-bit interval value indicator used to signal one of 10 or more desired pre-configured SPS intervals;

[0016] Figure 3B This is an example diagram of a MAC control element (CE) design that includes an interval indicator value and a system frame number (SFN).

[0017] Figure 4 This is an example diagram of a MAC PDU containing multiple MAC CEs;

[0018] Figure 5 This is a diagram illustrating an example of a request for an offset or an offset change;

[0019] Figure 6 This is a diagram illustrating the process of indicating SPS configuration changes;

[0020] Figure 7 This is a flowchart illustrating a shortened SPS reconfiguration method using response messages; and

[0021] Figure 8 This is a list of instance triggering events used for SPS reconfiguration. Detailed Implementation

[0022] Figure 1A This is an illustration of an exemplary communication system 100 that can implement one or more of the disclosed embodiments. The communication system 100 can be a multiple access system that provides content such as voice, data, video, messaging, and broadcasting to multiple wireless users. The communication system 100 enables multiple wireless users to access this content by sharing system resources, including wireless bandwidth. As an example, the communication system 100 can use one or more channel access methods, such as Code Division Multiple Access (CDMA), Time Division Multiple Access (TDMA), Frequency Division Multiple Access (FDMA), Orthogonal FDMA (OFDMA), and Single Carrier FDMA (SC-FDMA), etc.

[0023] like Figure 1AAs shown, the communication 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. However, it should be understood that any number of WTRUs, base stations, networks, and / or network components are contemplated in the disclosed embodiments. Each of the WTRUs 102a, 102b, 102c, 102d can be any type of device configured to operate and / or communicate in a wireless environment. For 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, and consumer electronic devices, etc.

[0024] The communication system 100 may also include base stations 114a and 114b. Each of base stations 114a and 114b may be any type of device configured to enable access to one or more communication networks (e.g., core network 106, Internet 110, and / or network 112) by wirelessly interfacing with at least one WTRU 102a, 102b, 102c, or 102d. As an example, base stations 114a and 114b may be base transceiver stations (BTS), node B, e-node B, home node B, home e-node B, site controllers, access points (APs), and wireless routers, etc. Although each of base stations 114a and 114b is described as a single component, it should be understood that base stations 114a and 114b may include any number of interconnected base stations and / or network components.

[0025] Base station 114a may be part of RAN 104, and the RAN may also include other base stations and / or network components (not shown), such as base station controllers (BSCs), radio network controllers (RNCs), relay nodes, etc. Base station 114a and / or base station 114b may be configured to transmit and / or receive radio signals within a specific geographical area called a cell (not shown). The cell may be further subdivided into cell sectors. For example, the cell associated with base station 114a may be divided into three sectors. Thus, in one embodiment, base station 114a may include three transceivers, that is, each transceiver corresponds to one sector of the cell. In another embodiment, base station 114a may use multiple-input multiple-output (MIMO) technology, and thereby can use multiple transceivers for each sector of the cell.

[0026] Base stations 114a and 114b can communicate with one or more of WTRUs 102a, 102b, 102c, and 102d via air interface 116, which can be any suitable wireless communication link (e.g., radio frequency (RF), microwave, infrared (IR), ultraviolet (UV), visible light, etc.). Air interface 116 can be established using any suitable radio access technology (RAT).

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

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

[0029] In other embodiments, base station 114a and WTRUs 102a, 102b, 102c may implement radio access technologies such as IEEE 802.16 (Global Microwave Access Interoperability (WiMAX)), CDMA2000, CDMA2000 1X, CDMA2000 EV-DO, Provisional Standard 2000 (IS-2000), Provisional Standard 95 (IS-95), Provisional Standard 856 (IS-856), Global System for Mobile Communications (GSM), Evolution for Enhanced Data Rates in GSM (EDGE), and GSM EDGE (GERAN).

[0030] As an example, Figure 1ABase station 114b can be a wireless router, home node B, home e node B, or access point, and can use any suitable RAT to facilitate wireless connectivity in a local area (e.g., business premises, residences, vehicles, and campuses). In one embodiment, base station 114b and WTRUs 102c and 102d can establish a wireless local area network (WLAN) by implementing a radio technology such as IEEE 802.11. In another embodiment, base station 114b and WTRUs 102c and 102d can establish a wireless personal area network (WPAN) by implementing a radio technology such as IEEE 802.15. In yet another embodiment, base station 114b and WTRUs 102c and 102d can establish a picocell or femtocell by using a cellular-based RAT (e.g., WCDMA, CDMA2000, GSM, LTE, LTE-A, etc.). Figure 1A As shown, base station 114b can be directly connected to the Internet 110. Therefore, base station 114b can access the Internet 110 without going through core network 106.

[0031] RAN 104 can communicate with core network 106, which can be any type of network configured to provide voice, data, application, and / or Voice over Internet Protocol (VoIP) services to one of WTRUs 102a, 102b, 102c, 102d or readers. For example, core network 106 can provide call control, billing services, location-based services, prepaid calling, internet connectivity, video distribution, and / or perform advanced security functions such as user authentication. While in Figure 1A Although not shown, it should be understood that RAN 104 and / or core network 106 can communicate directly or indirectly with other RANs, and these RANs can use either the same RAT as RAN 104 or a different RAT. For example, in addition to connecting with RAN 104 which uses E-UTRA radio technology, core network 106 can also communicate with another RAN (not shown) which uses GSM radio technology.

[0032] Core network 106 may also act as a gateway for WTRUs 102a, 102b, 102c, and 102d to access PSTN 108, the Internet 110, and / or other networks 112. PSTN 108 may include a circuit-switched telephone network providing Simple Old-Style Telephone Service (POTS). The Internet 110 may include a global interconnected computer network equipment system using common communication protocols, such as TCP, UDP, and IP from the Transmission Control Protocol / Internet Protocol (TCP / IP) suite. Network 112 may include wired or wireless communication networks owned and / or operated by other service providers. For example, network 112 may include another core network connected to one or more RANs, which may use the same RAT as RAN 104 or a different RAT.

[0033] In communication system 100, some or all of the WTRUs 102a, 102b, 102c, and 102d may include multi-mode capability; in other words, WTRUs 102a, 102b, 102c, and 102d may include multiple transceivers communicating with different wireless networks on different wireless links. For example, Figure 1A The WTRU 102c shown can be configured to communicate with base station 114a using cellular-based radio technology and with base station 114b using IEEE 802 radio technology.

[0034] Figure 1B This is an example system diagram of WTRU 102. (Example...) Figure 1B As shown, WTRU 102 may include a processor 118, a transceiver 120, a transmit / receive unit 122, a speaker / microphone 124, a keyboard 126, a display / touchpad 128, non-removable memory 130, removable memory 132, a power supply 134, a Global Positioning System (GPS) chipset 136, and other peripheral devices 138. It should be understood that, while remaining consistent with the embodiments, WTRU 102 may also include any sub-combination of the foregoing components.

[0035] Processor 118 can 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. Processor 118 can perform signal encoding, data processing, power control, input / output processing, and / or any other function that enables WTRU 102 to operate in a wireless environment. Processor 118 can be coupled to transceiver 120, which can be coupled to transmitter / receiver unit 122. Although Figure 1B While the processor 118 and transceiver 120 are described as separate components, it should be understood that the processor 118 and transceiver 120 can also be integrated together in an electronic component or chip.

[0036] The transmitting / receiving component 122 may be configured to transmit or receive signals to and from a base station (e.g., base station 114a) via an air interface 116. For example, in one embodiment, the transmitting / receiving component 122 may be an antenna configured to transmit and / or receive RF signals. As an example, in another embodiment, the transmitting / receiving component 122 may be an emitter / detector configured to transmit and / or receive IR, UV, or visible light signals. In yet another embodiment, the transmitting / receiving component 122 may be configured to transmit and receive both RF and optical signals. It should be understood that the transmitting / receiving component 122 may be configured to transmit and / or receive any combination of wireless signals.

[0037] In addition, although Figure 1B While the transmit / receive component 122 is described as a single component, the WTRU 102 may include any number of transmit / receive components 122. More specifically, the WTRU 102 may use MIMO technology. Therefore, in one embodiment, the WTRU 102 may include two or more transmit / receive components 122 (e.g., multiple antennas) that transmit and receive wireless signals via the air interface 116.

[0038] Transceiver 120 can be configured to modulate signals to be transmitted by transmitter / receiver 122 and demodulate signals received by transmitter / receiver 122. As described above, WTRU 102 can have multimode capability. Therefore, transceiver 120 can include multiple transceivers that allow WTRU 102 to communicate using various RATs (e.g., UTRA and IEEE 802.11).

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

[0040] The processor 118 can receive power from the power supply 134 and can be configured to distribute and / or control power for other components in the WTRU 102. The power supply 134 can be any suitable device for powering the WTRU 102. For example, the power supply 134 may include one or more dry cell battery packs (e.g., nickel-cadmium (Ni-Cd), nickel-zinc (Ni-Zn), nickel-metal hydride (NiMH), lithium-ion (Li-ion), etc.), solar cells, or fuel cells, etc.

[0041] 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) related to the current location of the WTRU 102. As a supplement or replacement to the information from the GPS chipset 136, the WTRU 102 may receive location information from base stations (e.g., base stations 114a, 114b) via the air interface 116, and / or determine its location based on signal timing received from two or more nearby base stations. It should be understood that, while remaining consistent with the embodiments, the WTRU 102 may acquire location information using any suitable location determination method.

[0042] The processor 118 may be further coupled to other peripheral devices 138, which may include one or more software and / or hardware modules providing additional features, functions, and / or wired or wireless connectivity. For example, peripheral devices 138 may include an accelerometer, electronic compass, satellite transceiver, digital camera (for photos and video), Universal Serial Bus (USB) port, vibration device, television transceiver, hands-free headset, etc. Modules, FM radio units, digital music players, video game console modules, and internet browsers, etc.

[0043] Figure 1C This is a system diagram of RAN 104 and core network 106 according to an embodiment. As described above, RAN 104 can communicate with WTRUs 102a, 102b, and 102c via air interface 116 using E-UTRA radio technology. RAN 104 can also communicate with core network 106.

[0044] RAN 104 may include eNodeBs 140a, 140b, and 140c; however, it should be understood that RAN 104 may include any number of eNodeBs while remaining consistent with the embodiments. Each of eNodeBs 140a, 140b, and 140c may include one or more transceivers communicating with WTRUs 102a, 102b, and 102c via air interface 116. In one embodiment, eNodeBs 140a, 140b, and 140c may implement MIMO technology. Thus, for example, eNodeB 140a may use multiple antennas to transmit and receive radio signals from WTRU 102a.

[0045] Each of eNodeB 140a, 140b, and 140c can be associated with a specific cell (not shown) and can be configured to handle radio resource management decisions, handover decisions, and uplink and / or downlink user scheduling, etc. For example... Figure 1C As shown, nodes B140a, 140b, and 140c can communicate with each other on the X2 interface.

[0046] Figure 1C The core network 106 shown may include a Mobility Management Entity Gateway (MME) 142, a Serving Gateway 144, and a Packet Data Network (PDN) Gateway 146. While each of the foregoing components is described as part of the core network 106, it should be understood that any of these components may be owned and / or operated by an entity other than the core network operator.

[0047] MME 142 can connect to each of the eNodeBs 140a, 140b, and 140c in RAN 104 via the S1 interface and can act as a control node. For example, MME 142 can be responsible for authenticating users of WTRUs 102a, 102b, and 102c, performing bearer activation / deactivation processes, selecting a specific serving gateway during the initial attach process of WTRUs 102a, 102b, and 102c, and so on. MME 142 can also provide control plane functions for handover between RAN 104 and other RANs (not shown) using other radio technologies (such as GSM or WCDMA).

[0048] Service gateway 144 can connect to each of the eNodeBs 140a, 140b, and 140c in RAN 104 via the S1 interface. Service gateway 144 typically routes and forwards user data packets to / from WTRUs 102a, 102b, and 102c. Furthermore, service gateway 144 can perform other functions, such as anchoring the user plane during handover between eNodeBs, triggering paging processes when downlink data is available to WTRUs 102a, 102b, and 102c, managing and storing the context of WTRUs 102a, 102b, and 102c, etc.

[0049] Service gateway 144 can also be connected to PDN gateway 146, which can provide WTRU 102a, 102b, 102c with access to packet-switched networks such as the Internet 110, in order to facilitate communication between WTRU 102a, 102b, 102c and IP-enabled devices.

[0050] Core network 106 can facilitate communication with other networks. For example, core network 106 can provide WTRUs 102a, 102b, and 102c with access to a circuit-switched network such as PSTN 108, thereby facilitating communication between WTRUs 102a, 102b, and 102c and traditional landline communication equipment. For example, core network 106 may include or communicate with an IP gateway (such as an IP Multimedia Subsystem (IMS) server), and the IP gateway may act as an interface between core network 106 and PSTN 108. Furthermore, core network 106 can provide WTRUs 102a, 102b, and 102c with access to network 112, which may include other wired or wireless networks owned and / or operated by other service providers.

[0051] Other networks 112 can be further connected to an IEEE 802.11-based wireless local area network (WLAN) 160. WLAN 160 may include an access router 165. The access router may include gateway functionality. Access router 165 can communicate with multiple access points (APs) 170a and 170b. Communication between access router 165 and APs 170a and 170b can be conducted via wired Ethernet (IEEE 802.3 standard) or any type of wireless communication protocol. AP 170a communicates wirelessly with WTRU 102d via an air interface.

[0052] 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 that use vehicles and roadside units as communication nodes in a communication network, thereby providing each other with information (such as safety warnings and traffic information). In avoiding accidents and traffic congestion, vehicle communication systems, as a collaborative approach, are more effective than each vehicle attempting to solve the problem individually.

[0053] Typically, vehicular networks are considered to contain two types of nodes: vehicles and roadside stations. Both are dedicated short-range communication (DSRC) devices. DSRC typically operates in the 5.9 GHz band, with a bandwidth of 75 MHz and a range of approximately 1000 meters.

[0054] Vehicle communication standards, including V2V, V2I, and V2P, can be developed by adapting to current LTE specifications. For example, V2V communication using existing device-to-device (D2D) frameworks (such as ProSe) can be considered.

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

[0056] Currently, D2D communication is being developed for public safety (PS) communications using LTE technology. Since PS applications often require radio communication in areas not typically covered by LTE network radio coverage (e.g., in tunnels, deep basements, or after a catastrophic system outage), there is a need to support D2D communication for PS in the absence of any operational network or before the arrival of radio infrastructure deployed in AdHoc. However, even when operating with operational network infrastructure, PS communication typically still requires higher reliability compared to commercial services.

[0057] For example, PS-type applications between first responders can include at least a key-based voice call service using multiple call groups. Furthermore, PS-type applications for effectively utilizing the capabilities provided by LTE broadband radio can include services such as video push or download.

[0058] It is foreseeable that once D2D communication is deployed, it can be used not only for PS-type applications but also for commercial use cases. One example could be utility companies, which typically need to support two-way radio communication in areas not covered by network infrastructure. Furthermore, D2D services (such as discovery) could be a suitable signaling mechanism that allows the use of LTE-based radio access in commercial use cases to implement proximity-based services and traffic offloading.

[0059] D2D communication using LTE-based radio access can be designed to operate in both network-controlled mode and WTRU autonomous mode, hereinafter referred to as Mode 1 and Mode 2, respectively. Mode 1 (network-controlled mode) may only be feasible under certain conditions, such as when the D2D terminal is within the radio coverage range of an LTE base station. If the WTRU cannot communicate with the LTE base station, the D2D terminal can fall back to Mode 2 (WTRU autonomous mode). In this case, it primarily uses the channel access parameters pre-stored within the terminal itself.

[0060] For D2D communication using Mode 1, the LTE base station can reserve a selected set of uplink (UL) subframes to allow D2D transmissions. The LTE base station can also announce a set of UL subframes with associated parameters that can receive D2D transmissions for neighboring cells or Mode 2 terminals. Not all LTE system bandwidth (BW) within the subframes reserved for D2D is necessarily available for D2D transmissions. When operating in Mode 1, the serving cell can license radio resources for D2D communication to the D2D terminal. Prior to a D2D license from the network, the terminal can perform UL transmissions on the cellular UL channel, thereby indicating the amount of available D2D data to the base station. The D2D license received by the D2D terminal from the LTE base station on the cellular DL channel allows the D2D terminal to use certain selected radio resources, namely certain radio blocks (RBs) appearing on some subframes in a given scheduling period.

[0061] A D2D terminal can send a scheduling assignment (SA) message in one or more D2D subframes of the first group, and then send D2D data in D2D subframes of the second group 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. The D2D data packets may include a Media Access Control (MAC) header with source and destination addresses. Multiple logical channels can be multiplexed and can be sent by a WTRU as part of a single transport block (TB) within a designated D2D subframe.

[0062] For D2D communication using Mode 2, the D2D terminal can autonomously select time / frequency radio resources. Channel access parameters can be pre-configured and stored in the D2D terminal, such as subframes, scheduling periods, or surveillance subframes for transmitting SA control messages and corresponding D2D data. Except for the preceding UL traffic indication and DL D2D licensing phase, the Mode 2 terminal follows the same transmission behavior as the Mode 1 terminal, and will also transmit SA during the scheduling period, followed by D2D data transmission.

[0063] For D2D communication modes 1 and 2, the D2D terminal can also transmit auxiliary D2D signals (such as D2D synchronization signals and channel messages) to help the receiver demodulate its transmission.

[0064] D2D communication using LTE-based radio access can carry voice channels, data packets, or data streams. A special case of D2D communication is D2D discovery service. Unlike voice channels, D2D discovery typically requires only small packet transmissions, which are usually adapted to one, two, or at most a few subframes. For example, these packets may contain application data to announce the availability of a device or software (SW) application to perform D2D data exchange with nearby terminals.

[0065] D2D discovery may or may not use the same channel access protocol, such as the channel access protocol used for D2D communication for voice or general D2D data. For D2D discovery, if within the coverage area of ​​an LTE base station, D2D discovery resources can be allocated separately from those used for D2D communication for voice or general D2D data. The D2D terminal can autonomously select radio resources for its D2D discovery message (e.g., type 1 discovery) from the resource set reserved by the eNB and time-frequency radio resources periodically recurring in certain UL subframes, or the LTE serving cell can explicitly allocate these resources to the D2D terminal (e.g., type 2 discovery). The latter case is similar to D2D communication mode 1. In this case, scheduled assignment transmission may not be required when transmitting a D2D discovery message. However, in some cases, even a D2D terminal transmitting only a D2D discovery message may still need to transmit an auxiliary D2D synchronization signal to assist the receiver.

[0066] In addition to identifying potential enhancements to LTE (D2D and potentially non-D2D) needed to meet SA1 requirements, 3GPP is currently evaluating the feasibility of V2X communications based on the current D2D LTE specification. As part of this feasibility study, 3GPP has identified four main V2X scenarios.

[0067] Scenario 1 supports V2V operations based solely on PC5. PC5 includes direct communication via ProSe on the PC5 interface (side link) between WTRUs to transmit V2X data from the source WTRU (e.g., a vehicle) to the destination WTRU (e.g., another vehicle, road infrastructure equipment, or pedestrian, etc.).

[0068] Scenario 2 supports V2V operations based solely on Uu. Uu includes transmitting V2X data from the source WTRU (e.g., a vehicle) to the destination WTRU (e.g., another vehicle, road infrastructure equipment, or pedestrian, etc.) via the eNB on the Uu interface (uplink and downlink).

[0069] Scenario 3A involves a WTRU transmitting V2X messages to other WTRUs in a side link. One of the WTRUs performing the receiving action is a WTRU-type Roadside Unit (RSU), which receives the V2X message in the side link and transmits the message to the E-UTRAN in the uplink. The E-UTRAN receives the V2X message from the WTRU-type RSU and then transmits it to multiple WTRUs located in the local area in the downlink.

[0070] Scenario 3B includes a WTRU transmitting a V2X message to the E-UTRAN in the uplink, and the E-UTRAN forwarding the V2X message to one or more RSUs of the WTRU type. The RSUs of the WTRU type then forward the V2X message to other WTRUs in the sidelink.

[0071] LTE can use semi-persistent scheduling (SPS) as its semi-static resource allocation method to avoid the scheduling overhead associated with dynamic scheduling of resources for services that have transmissions occurring periodically with relatively small payloads (such as VoIP). SPS is feasible for both uplink and downlink transmissions.

[0072] For uplink SPS, when new data arrives at the WTRU's buffer, the WTRU can use a Buffer Status Report (BSR) message to report an indication of its buffer status. The BSR control element typically contains a logical channel group ID and one or more fields corresponding to the buffer size. Sidelink-specific BSRs may also contain a destination index, since any sidelink buffered data corresponds to a transmission to another WTRU, not the eNB performing the reporting.

[0073] SPS (Segmented Resource Scheduler) allows for scheduling of terminals on the Physical Downlink Control Channel (PDCCH) to indicate valid licenses every N subframes. The period or value N of the SPS resource is provided via Radio Resource Control (RRC) signaling, while activation / deactivation and resource details are provided by PDCCH signaling using the SPS Cell Radio Network Temporary Identifier (C-RNTI). Dynamic scheduling commands appearing in the same subframe as the SPS resource can take precedence over the SPS resource. This behavior is particularly useful if there is an occasional need to increase the periodic resources allocated to the WTRU (WTRU).

[0074] SPS retransmissions for downlink can always be dynamically scheduled, while for uplink, they can be either dynamically scheduled or follow semi-persistent subframe allocation. Furthermore, SPS is only supported in primary cells (PCell) or primary / secondary cells (PSCell) (for dual connectivity (DC)).

[0075] One of the fundamental message types transmitted for V2X traffic is the Collaborative Awareness Message (CAM). CAM messages contain collaboratively aware information exchanged between road users and roadside infrastructure to learn about the location, movement, and attributes of other vehicles. The regular exchange of this information is crucial for several road safety and traffic efficiency applications.

[0076] A CAM message consists of specific containers, which can be mandatory or optional. Each CAM message may include at least one basic container (containing basic information related to the originating Intelligent Transmission System Station (ITS-S)) and a high-frequency container containing high-dynamic information about the originating ITS-S. In addition, a CAM message may also include a low-frequency container containing static and non-high-dynamic information about the originating ITS-S, and one or more special containers containing information about the vehicle role of the originating ITS-S (i.e., for a specific vehicle).

[0077] Some exemplified ITS elements include: active traffic management systems; traffic cameras for monitoring weather, traffic congestion, or other incidents; variable message signs that may contain Amber Alerts or other messages; highway traffic broadcasts; road and weather information systems; ramp meters; traffic data collectors; and traffic management centers.

[0078] CAM message transmission can be periodic, with some deviations or adjustments based on the vehicle's direction of travel, speed, position, and the time elapsed since the last CAM message was generated. Furthermore, if the time elapsed since the last CAM message was generated using the same low-frequency container is equal to or greater than 500 milliseconds, then that low-frequency container must be included in the CAM. The same rule applies to special containers.

[0079] For V2X communication to be used, E-UTRAN should be able to support a maximum latency of 100 milliseconds for most use cases. While the pre-collision sensing use case has a more stringent requirement of 20 milliseconds, the basic assumptions in 3GPP for standardizing any V2X-related enhancements require a RAN-related latency of 100 milliseconds.

[0080] Because CAM traffic is generally periodic, SPS is the preferred candidate for V2V message transmission on the UL in scenarios 2 and 3 as described above. However, in urban scenarios, there are a large number of vehicles that need to transmit in the uplink, so the UL capacity on the Uu is unlikely to meet SPS periods of 40 milliseconds or less, and therefore a larger SPS period needs to be considered.

[0081] This document provides methods for determining, reporting, and receiving SPS period and offset change indicators. The latency occurring during CAM message transmission in E-UTRAN can include one or more of the following factors. As a first component, latency can include the time between the time it takes for the V2X application to generate the CAM message and the time it takes for the next ULSPS resource allocated to the WTRU to be available. As a second component, latency can include the time required to receive and process the CAM message on the network, and may further depend on whether the CAM message is sent to the core network or whether processing is maintained at the eNB. As a third component, latency can include the time required to transmit the message to the destination WTRU using Single Cell Point-to-Multipoint (SC-PTM), Evolved Multimedia Broadcast Multicast Service (eMBMS), or unicast scheduling in the downlink channel.

[0082] As the SPS period increases, the portion attributable to the delay of the first component will increase. This increase can only be avoided if CAM message generation is indeed periodic and the SPS period can be aligned with CAM message generation.

[0083] Based on the CAM generation frequency, no assumptions need to be made about the actual periodicity, and compared with the SPS style, the CAM generation style will encounter periodic and offset changes.

[0084] In CAM generation patterns, periodicity can change. For example, the CAM generation interval may change dynamically, shifting between 100 milliseconds (when vehicle position, direction of travel, and speed change) and 1 second (when vehicle position, direction of travel, and speed do not change). Furthermore, for multiple CAM generation intervals specified by the Collaborative Awareness (CA) base service, the period can be any value between these values ​​during certain time periods. As a result, the CAM generation period can change dynamically over time and theoretically exhibit any period between 100 milliseconds and 1 second.

[0085] Offset changes may occur in CAM generation patterns. If the CAM interval is not an integer multiple of 100 milliseconds, the conversion between one CAM interval and another may cause a change in the offset between message generation processing and fixed SPS scheduling.

[0086] Accordingly, these changes in the CAM message generation style may increase the first latency component and may fail to meet the 100 ms latency requirement when using SPS.

[0087] Furthermore, the payload size can be variable. SPS is best suited for periodic traffic with a predetermined resource allocation size, such as Voice over Internet Protocol (VoIP). While variations in message size can be easily handled by dynamic scheduling, frequent dynamic scheduling can lead to increased scheduling overhead and potentially significantly reduce the benefits of SPS. This reduction in benefits is even more pronounced for V2V traffic that assumes (at least in urban scenarios) a dense concentration of vehicles that need to periodically receive such dynamically scheduled traffic. On the other hand, over-allocating resources will waste SPS resources that could be used by the scheduler for other purposes.

[0088] When a CAM message contains only high-frequency containers, it can be approximately 190 bytes; when it contains high-frequency containers and one or more low-frequency containers, it can be approximately 300 bytes. Furthermore, CAM messages with special containers may deviate from these sizes. Therefore, the size of CAM messages can vary considerably. The SPS allocation size can be defined in a more dynamic way, rather than solely relying on dynamic scheduling.

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

[0090] The following concepts are introduced here: WTRU can send requests for offsets or offset changes regarding SPS; WTRU can send instructions to change SPS configurations; WTRU can send instructions to release specific resources; multiple SPS configurations can be provided, and activation / deactivation methods for these configurations are disclosed; the SPS message size can be configured through the application layer; the SPS message size can be associated with the QCI of a logical channel; allocation size changes can be piggybacked on SPS transmissions; methods for periodically increasing the SPS allocation size will be disclosed; WTRU can request SPS based on application-derived triggers; WTRU can receive enhancements for SPS configurations. These enhancements may include the format and timing of auxiliary information, permissible offsets that can be requested for WTRU changes, an SPS configuration index, and permissible logical channels for SPS or resource configurations. New triggers for sidelink BSRs can be provided to send offset change information. Application-based triggers calculated by the access layer (AS) for sending SPS configuration / offset changes or activation / deactivation can be based on upper-layer information. Logical channel priority (LCP) can be applied to SPS licensing based on the association between logical channels and SPS configurations. If simultaneous licensing occurs, the WTRU can select a single SPS license. Furthermore, it discloses enabling / disabling the use of the SPS based on timing compensation and interval information, as well as providing a timing-based LTE adaptation layer.

[0091] The term "WTRU" as described herein can represent a single device enabling D2D communication, which can be an actual mobile device, a vehicle with D2D communication capabilities, and / or a roadside unit designed to enhance V2X system performance. "WTRU" can further represent a mobile device communicating directly with an eNB. Similarly, the term "eNB" represents a traditional eNB used in LTE infrastructure communications, which can provide communication services for D2D communication within its coverage area. The eNB can be deployed on cell towers or can be deployed itself as a roadside unit, where, in the latter case, the eNB may have functionality limited to D2D communication.

[0092] As further described herein, CAM messages will be referred to, specifically referring to V2V-related application messages transmitted via the AS radio interface. In the described embodiments, CAM messages can represent any type of upper-layer message that needs to be transmitted by the WTRU using SPS on the uplink or sidelink. Such messages may have time-critical or latency-sensitive attributes. For most of the time, or for a considerable period, such messages can be further considered periodic, with their period, timing (offset), or message size occasionally varying.

[0093] Figure 2A diagram illustrating an example timeline for CAM timing 200 is shown. Considering... Figure 2 The illustrated timeline illustrates the potential problems associated with using a fixed SPS period (e.g., 100 milliseconds) for high-volume scenarios that are highly reasonable for vehicles. In this example, the vehicle performs the following activities, as indicated by the illustrated timeline below.

[0094] After a period of time during which the vehicle meets the first condition (e.g., a change in speed, position, or direction of travel), at 204, the vehicle no longer meets condition 1 (e.g., the vehicle arrives at a station). At 206, when the vehicle starts moving again, it begins to meet condition 1 again. At 208, the vehicle may begin to decelerate. At 210, the vehicle no longer meets condition 1, and it arrives at a station. Then, after the last CAM and 160 milliseconds have elapsed, the vehicle meets condition 1 again, for example, at 212, and it starts moving again, but the movement is very brief. Then, in three intervals, CAMs will be spaced 160 milliseconds apart until they revert to appearing at 1-second intervals.

[0095] Accordingly, timeline 200 shows the timing of CAMs using the SPS configuration with a 100-millisecond cycle. This configuration may result in a significant amount of SPS resources that are not used by WTRUs 214 and 216 and cannot be reused by the scheduler. Although resources can be implicitly released after the WTRU performs multiple empty transfers, the frequent transitions between the two states still lead to some resource waste, and the WTRU still needs to communicate with the eNB to reallocate resources. Furthermore, this configuration can potentially generate significant latency (ranging from 30 to 90 milliseconds). These significant latency needs to be added to the total E-UTRAN latency for V2X messages and may prevent the 100-millisecond requirement from being met.

[0096] It should be understood that while the aforementioned problem is described with reference to CAM messages, other types of application-related traffic may also experience this issue, such as VoIP, real-time control, etc. Therefore, the embodiments disclosed herein can be applied not only to V2V use cases, but also to any use case with traffic exhibiting properties similar to CAM.

[0097] In the described SPS configuration, the WTRU may request to use the SPS and / or the SPS configuration may be provided by the eNB. For example, the WTRU may request to use the SPS from the eNB. Such a request may be sent by the WTRU via RRC signaling. As an example, the WTRU requesting the SPS from the eNB may perform this process using the WTRU Sidelink Information (WTRU Sidelink Information) RRC message. In an embodiment using the adaptation layer described herein, the WTRU may send an SPS usage request as a result of a trigger from an upper layer.

[0098] The WTRU can include one or more information elements related to the parameters of the SPS in the SPS configuration request. For example, the WTRU can include information related to one or more desired SPS configurations, where each SPS configuration includes one or more of the following: the periodicity and / or offset of the SPS configuration, the transport size (e.g., transport block size (TBS)), the number of resource blocks, etc. In another example, the WTRU can include information related to the desired parameters of one or more requested SPS configurations in the form of a set of indexes, each index pointing to a row in a pre-configured table, where each row lists the set of desired SPS parameters for the desired SPS configuration.

[0099] In response to an SPS request from the WTRU, the eNB can transmit the SPS configuration to the WTRU. Alternatively, the eNB can transmit the SPS configuration to the WTRU without an SPS request, and thus can transmit the SPS configuration either autonomously or through some other trigger.

[0100] To transmit messages on Uu, the WTRU can use existing uplink SPS in LTE. Furthermore, a sidelink SPS can also be configured with a similar SPS configuration, which can be transmitted either via RRC messages or via a combination of RRC messaging with MAC control elements (CE) and PHY messaging on the PDCCH. The uplink or sidelink SPS configuration may further include configuration of WTRU auxiliary information (e.g., configuration information) and / or sidelink configuration.

[0101] WTRU auxiliary information includes information sent by the WTRU to the eNB to help the eNB adjust SPS parameters. Different types of configuration information related to WTRU auxiliary information are possible. The WTRU can receive WTRU auxiliary information configuration, which relates to whether SPS scheduling-related auxiliary information can be provided to the eNB, what type of auxiliary information (e.g., timing, periodicity) can be provided, and how to send the information. WTRU auxiliary information configuration can allow or disable the WTRU from transmitting SPS scheduling auxiliary information. The WTRU can receive a list of possible timing offsets for SPS resource patterns, where the offsets can be defined relative to a specific SFN / subframe number and / or relative to the beginning of a scheduling period. The WTRU can receive a list of possible SPS periods / intervals that it can select or request to change. The list of possible SPS periods / intervals can be a subset of possible SPS periods that can be supported by the WTRU or allocated or assigned by the eNB to a specified WTRU. The WTRU may request to change only one periodicity in the eNB's configured periodicity list. The WTRU can receive configuration of resources (e.g., UL) used to transmit auxiliary information. For example, this auxiliary information can be sent using dedicated SR resources configured by the eNB specifically for this purpose. The WTRU can receive permissible time instances and frequencies available for sending auxiliary information. For example, the WTRU can be configured to provide assistance at the end of each scheduling cycle, or periodically based on the cycle configured by the eNB.

[0102] For sidelinks, SPS configurations for subframes corresponding to SPS resources can be provided in each scheduling cycle. These subframes can be the same in each scheduling cycle, and the subframes used for retransmitting data transmitted using SPS and the required number of retransmissions can be further specified.

[0103] The WTRU can receive a list of possible SPS resource configurations that can be enabled in the SPS configuration. This list can be implemented using a set of indexes pointing to a predefined lookup table. The WTRU can activate one of the possible SPS configurations from this list. Alternatively, the WTRU can have multiple SPS configurations active simultaneously.

[0104] Resource configurations for each SPS configuration or each configuration in the SPS configuration list are available. For example, each SPS configuration can correspond to a specific SPS resource pattern with periodicity (i.e., interval), timing offset, allocation size, actual resources used (resource blocks), or allocation size pattern. The allocation size pattern can be defined such that one of a certain number of SPS resources has a different size (i.e., increases or decreases) in the resource quantity associated with the SPS allocation size. For sidelink SPS, resource configurations can be configured in the same way as for uplink SPS, where the interval / period is configured in RRC, and the eNB can indicate the timing / offset and resource configuration to the WTRU (e.g., via PHY layer signaling). For sidelink, the PHY layer signaling can be a PDCCH with DCI format 5 sent using the SPS C-RNTI configured in the RRC layer. Alternatively, for sidelink SPS, the resource configuration can all be sent in an RRC message (e.g., the interval, offset, and allocation size and / or allocation pattern can be sent via RRC messages).

[0105] The SPS configuration may further include identifiers of data that should be transmitted or prioritized by the WTRU when using each specific SPS configuration. These identifiers may take the form of: an allowed logical channel, a logical channel group, a priority (e.g., ProSe Packet-by-Packet Priority (PPPP)), a radio bearer, an application ID, or a QCI, etc. As an example, the WTRU may be configured to have multiple SPS configurations, and each SPS should be used to transmit data for a specific logical channel or logical channel group.

[0106] The SPS configuration may further include an identifier for one or more sidelink destination IDs to which the SPS configuration applies.

[0107] SPS timed changes are also possible. WTRUs for sending requests for SPS offsets or offset changes are provided here. For example... Figure 2 As shown in the timeline, to avoid additional CAM message delivery delays associated with waiting for the next SPS resource to transmit pending CAMs, the CAM message generation process should be synchronized with the SPS resource timing. If it is assumed that CAMs and SPSs have the same interval, then this waiting delay will be zero.

[0108] However, the SPS offset configured by the eNB (which is the timing of the PDCCH with SPS C-RNTI for UL SPS) is entirely determined by the eNB, and therefore cannot be guaranteed using the current SPS mechanism.

[0109] In one example, the WTRU can send the expected start subframe (i.e., offset) for SPS resources to the eNB to allow the eNB to trigger SPS resource allocation / reallocation, thereby aligning it with CAM message generation. Specifically, the WTRU can send a time offset (e.g., in the form of a System Frame Number (SFN) and / or subframe index) to the eNB to indicate the time at which it expects (begins) to have available SPS resources. After the WTRU sends the signal to the eNB, the time offset (or "offset") can also be implicitly sent to the eNB by assuming that the SFN and / or subframes have a fixed, predefined number of subframes.

[0110] Alternatively, the WTRU can instruct the eNB to delay or move the current offset of the SPS by a certain amount of time. For example, the WTRU may have been configured with an SPS configuration and a specific time offset or start point for that SPS configuration. The WTRU can instruct the eNB to move, delay, or advance the timing or start point of the SPS configuration by a certain number of subframes relative to the current timing of the resource.

[0111] The WTRU can be configured to have multiple timing options. For example, to reduce the signaling associated with request offset changes performed by the eNB, the eNB can further configure a set of possible timing offsets for the WTRU, where a particular timing offset can be active at a specified time, and the WTRU can request a replacement timing offset in a request offset change message.

[0112] The WTRU can receive multiple possible offsets in the RRC message configuring SPS. These offsets can be indicated as offsets with a specific SFN / subframe defined or provided in the same configuration, or as offsets with the initial resource configuration in the PDCCH message indicated by the SPS C-RNTI, where the SPSC-RNTI can initially allocate SPS resources for that configuration.

[0113] WTRU can further receive or associate an index pointing to each possible offset in the RRC message.

[0114] When sending a request for offset change to the eNB, the WTRU can indicate the desired offset it wishes to use by indicating the index associated with one of the configured offsets.

[0115] Figure 3AThe use of the 4-bit interval value indicator 300 is disclosed. Using four bits, the value 302 can represent the interval size. This example shows up to 16 different intervals, thus assuming four bits. Here, the value 0000304 corresponds to the smallest interval 306, which is 100 milliseconds in size. The maximum value 1001 308 shown corresponds to the long interval 310, which is 1 second in size. Figure 3B An illustrative MAC control element 320 is shown, which includes a 4-bit interval indicator 322 and a 10-bit system frame number 324 used as an offset. The system frame number can be reduced by 10 bits by using an SFN offset from the current SFN instead of 0.

[0116] Different types of information can be provided in offset request or offset change messages. A request for an offset or offset change may include any of the following: the SFN and / or subframe offset of the SPS (i.e., the timing of one of the SPS resources), the time offset of the required SPS resource style relative to the current time style (positive or negative, and possibly based on frames, subframes, or certain subframe units, such as scheduling periods), an index to identify one of several possible timing offsets for the SPS resource style (possibly configured by the eNB, or predefined), and an identifier of the SPS process whose timing needs to be changed (if multiple SPS processes are configured).

[0117] The SFN and / or subframe offset of an SPS (e.g., the timing of one of the SPS resources) can be represented by any of the following: the absolute SFN and subframe of the first SPS resource (other resources are separated by the configured SPS period); the offset from a predefined fixed subframe (e.g., SFN 0 (mod x) and subframe 0); the offset from the start of the scheduling period associated with the sidelink resource pool; and / or the offset from the initial transmission performed by the eNB using: 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 after its configuration.

[0118] For an index that identifies one of several possible timing offsets for an SPS resource pattern (which may be configured or predefined by the eNB), the eNB can send a set of permissible offsets with the index in the SPS configuration, and the WTRU can provide offset changes by providing the index corresponding to the desired offset.

[0119] For the identifier of an SPS process whose timing needs to be changed (if multiple SPS processes are configured), such an identifier can be generated by sending an index that references the index provided by the eNB during the configuration of the multiple SPS processes. Such an identifier can also be generated by sending an index corresponding to the order of SPS grants relative to a specific frame / subframe combination (e.g., SFN x mod y, subframe 0).

[0120] This type of information concerning requests for offsets or offset changes is further referred to as offset change information.

[0121] The WTRU can use one or more of the following to send such requests regarding offset or offset changes. Requests regarding offset can be provided in an RRC message containing an offset change message, which may arrive after an RRC Radio Resource Configuration message configuring the SPS in the WTRU, or at any time after the WTRU connects to the eNB. Requests regarding offset can also be provided in a MAC Control Element (CE) containing offset change information.

[0122] A request for offset can be provided in a BSR that includes offset change information. Specifically, the WTRU can trigger a BSR when it determines that the SPS allocation timing needs to be changed. If the SPS resource and transport are located on PC5 instead of UL, then the BSR can be a sidelink BSR. Offset change information can also be included in either the BSR or the sidelink BSR.

[0123] For example, a BSR or sidelink BSR may include SFN and subframe information, time offset, or an SPS configuration index in a new field. This information may be further associated with logical channel groups that the WTRU can use to transmit data using the SPS configuration. This information may take the form of one or more additional fields for the buffer size associated with the logical channel group.

[0124] A BSR or sidelink BSR may include SFNs, subframes, and time offsets that can be transmitted instead of the buffer size for a specific logical channel group. WTRUs may use a special destination index field, logical channel group, or a combination of both to indicate the corresponding buffer size field in order to indicate SPS timing information.

[0125] A BSR or sidelink BSR may contain a special flag indicating that the SPS timing change was requested as a result of transmitting the BSR. The new timing of the requested SPS configuration can be indicated by the time instance for the WTRU to transmit the BSR. For example, the WTRU may indicate that the new SPS offset or timing corresponds to the number of subframes (possibly zero) following the subframe transmitting the BSR.

[0126] A BSR or sidelink BSR can contain an index associated with one of the predefined or permissible time offsets of the SPS style.

[0127] Offset requests can be provided in physical (PHY) layer messages, such as, but not limited to, scheduling requests (SRs), physical uplink control channels (PUCCHs), sounding reference signals (SRSs), or random access procedures (RACHs). For example, a special dedicated SR resource can be allocated to the WTRU to transmit the desired SPS offset. If multiple SPS configurations exist, different SRs can be configured. The actual SFN and offset used for the start of an SPS resource can be understood as occurring on a certain number of subframes after the subframe for which the WTRU transmits the special SR, such as on the same subframe or after a predetermined number of subframes known to both the WTRU and the eNB.

[0128] WTRU can transmit a request offset message at any time during the operation to change the offset of the current SPS resource. For example, Figure 2 The timeline shown illustrates a transition that alters the offset between the SPS and CAM, but all intervals remain the same. As a result of this transition, the WTRU can send an offset request message to the eNB. The following section describes in more detail the triggering conditions that cause the WTRU to send an offset request message.

[0129] The WTRU receives timing change acknowledgments from the eNB. Specifically, after transmitting a request offset message, the WTRU can receive acknowledgments from the eNB regarding timing changes that provide new timing for the SPS configuration. Such acknowledgments can be received using any of the following: a PDCCH message, a MAC CE message, or an RRC message.

[0130] For PDCCH messages, a timed change acknowledgment can be indicated by a new timed SPS C-RNTI that identifies the SPS configuration and SPS resources. If multiple SPS configurations exist, each SPS configuration can be represented by a separate SPS C-RNTI.

[0131] Figure 4This is an illustration of an example MAC header 402 and MAC payload 404 containing multiple MAC CEs 406, 408. For one or more MAC CE messages 406, 408, the timing change acknowledgment can be indicated by a message containing the new timing (e.g., using SFN and / or subframe offset) and an SPS configuration identifier, indicated herein by interval I2. Subframe number 412 can be included in the MAC CE. MAC payload 404 can additionally include one or more MAC SDUs 414 and padding bits 416.

[0132] For RRC messages, timing change confirmation can be indicated by a message containing the new timing (SFN and / or subframe offset) and the SPS configuration identifier.

[0133] Once a timing change confirmation is received from the eNB, the WTRU can apply / assume / infer the new timing for the resource. The WTRU can further assume that the new timing was provided in the offset request message (if the eNB did not provide timing), or it can also assume that the new timing was provided in the timing change confirmation from the eNB.

[0134] The WTRU can receive acknowledgments from the slave eNB using either the PDCCH or MAC CE. In this case, the WTRU can assume that the existing RRC configuration of the SPS is maintained and that periodic changes are only applied using the information in the acknowledgment message. If the WTRU receives an acknowledgment using RRC, the acknowledgment can further provide the new configuration of the SPS. The WTRU can then use the configuration provided in the acknowledgment message to update its RRC configuration.

[0135] As an example, after transmitting the request offset message, the WTRU can receive the corresponding PDCCH using the SPS C-RNTI to signal the SPS timing change with the new offset. The WTRU can assume that the previous SPS resource timing (with the old offset) will continue until it receives a PDCCH with the SPS C-RNTI (which should appear at the requested offset).

[0136] Figure 5An example of the timing of message passing 500 for processing a request for offset or offset change is shown, where the WTRU sends a request for offset or offset change regarding SPS. The vehicle or WTRU 502 may transmit an RRC connection request 506 to the eNB 502. In response, the WTRU 502 may receive an RRC connection reconfiguration message 508. The RRC connection reconfiguration message may include spsConfig. A CAM message may be initiated by the application layer 510. The WTRU 502 may transmit an offset request message 512. The WTRU may receive an SPS C-RNTI 514 on the PDCCH. The WTRU may begin using the SPS resource at the requested offset 516. If an offset change 518 is determined by the application or otherwise, the WTRU 502 may transmit another offset request message 520. Once a PDCCH with an SPS C-RNTI 522 is received, the WTRU may begin using the SPS resource at the newly requested offset 524.

[0137] This section provides the triggering conditions that cause the WTRU to send an offset or offset change to the eNB. Based on any information provided by the upper layer as defined below (e.g., upper layer message arrival timing indication, cycle change indication, timing change indication, upper layer marked messages, timing-based information provided by the WTRU to the upper layer, and information related to dynamic changes in the vehicle), the WTRU may determine that it is necessary to send an offset change to the eNB based on one or more of the following triggering conditions.

[0138] The trigger condition could be receiving a timed change instruction from the upper layer.

[0139] The triggering condition can be indicated by the timing of the arrival of a message from the upper layer that may be associated with a specific PPPP or QCI, or by the timing of a message going to a specific radio bearer or logical channel, etc., and must meet one of the following conditions.

[0140] If the time between receiving an upper-layer instruction and the subsequent scheduling of the next SPS resource exceeds a certain threshold Ta or is less than a certain threshold Tb, a trigger will be initiated. The threshold Tb can correspond to the processing latency assumed for the AS; therefore, a time difference less than the threshold is equivalent to the AS requiring a processing latency exceeding that time difference.

[0141] If the time difference between the arrival of the current message and the previous message is different from the previous Na time intervals between message arrivals (e.g., the difference from the configured number), or different from the determined message periodicity (e.g., the difference from the predefined configured amount) (which can be provided by the application layer or determined by the WTRU lower layer), then a trigger will be invoked.

[0142] If the message arrival timer is closer in time to another possible SPS resource timer (e.g., configured by the eNB), then a trigger will be invoked.

[0143] If the above timing condition occurs multiple times consecutively (xNb), it will trigger.

[0144] If the WTRU sends information about the expected offset or timing of the SPS, then the WTRU can calculate that information based on one or more of the following.

[0145] WTRU can select a timing offset that is consistent with any subframe that is at least Tc milliseconds after the CAM message timing (where Tc can be zero).

[0146] The WTRU can select a timing offset consistent with a subset of allowable subframes or an allowable timing, wherein the allowable timing is at least Td milliseconds after the CAM message timing, and also minimizes the time difference between the SPS resource and the CAM message timing. The subset of allowable subframes can be configured by the eNB. For example, the subset of allowable subframes may include allowable D2D subframes for sidelinks, wherein the subframes are defined by the TRPT or D2D subframe pattern of the WTRU defined by the eNB for the WTRU, or by the WTRU transport pool on PC5. The WTRU can select one of the pre-configured timing offsets pre-configured by the eNB, wherein the offset minimizes the time difference between the SPS resource and the CAM message timing.

[0147] In another example, the WTRU can send an indication to the network (e.g., the eNB) to change the SPS configuration, specifically the period and / or scheduling interval of the SPS configuration. For instance, the WTRU can send an indication to the eNB requesting a change to the scheduling interval of the current SPS configuration. Specifically, once triggered from an upper layer (e.g., detecting a need to change the CAM frequency due to vehicle dynamics), the WTRU can inform the eNB that a change in the SPS configuration (e.g., scheduling interval and / or offset) is required. As a result of this indication, the WTRU can assume that the configuration change is in effect. Alternatively, the WTRU can receive from the eNB a message with the new SPS configuration or confirmation of the configuration change requested by the WTRU. The configuration change can then take effect at any of the following times (i.e., when the WTRU begins using the new SPS configuration resources): upon receiving an indication from the eNB (e.g., based on the WTRU receiving an acknowledgment (ACK) from the eNB (e.g., via the Physical Hybrid ARQ Indicator Channel (PHICH)); at some future time of the WTRU indication; at a future time that is statically defined (i.e., in the WTRU specification) and related to the last SPS resource allocation, the time when the eNB receives the indication (e.g., determined by the WTRU transmission time and / or by receiving an ACK from the eNB on the PHICH), the time when the WTRU transmits the indication to the eNB, or the time explicitly provided in the indication; when the WTRU receives a new SPS configuration provided by the eNB; and / or when the WTRU receives an acknowledgment indicating that the eNB has received the indication. The acknowledgment indicating that the eNB has received the indication can be sent by one or more of the following: one or more RRC messages (e.g., SPS release prior to the new SPS configuration); the use of the SPS associated with the configuration. PDCCH license for C-RNTI; PDCCH using the new C-RNTI or the new downlink control information (DCI) format; and / or new MACCE.

[0148] Based on any information provided by the upper layer as defined in Section 4.1.5, the WTRU can determine that it is necessary to send an indication to change the SPS configuration. As a result of this triggering, the WTRU can send an indication to the eNB to change the SPS configuration.

[0149] This section provides the triggering conditions that cause the WTRU to send an SPS configuration change to the eNB. For example, based on any of the information provided by the upper layer as defined below (e.g., upper layer message arrival timing indication, cycle change indication, timing change indication, upper layer marked messages, timing-based information provided by the WTRU to the upper layer, and information related to dynamic changes in the vehicle), the WTRU may determine that it is necessary to send an indication to change the SPS configuration.

[0150] If the AS, the adapter layer described below, or the application layer determines that the CAM message period has changed, a trigger will be invoked. Such determination (whether performed by the AS or the adapter layer) can follow the rules defined below that allow the adapter layer to manage the SPS used for the CAM messages described below, and can be based on information provided by higher layers.

[0151] An AS or V2X application layer running on a WTRU may trigger this event before, during, or after the generation of a CAM that is sent using a CAM interval different from the previous interval.

[0152] Once it is determined that the CAM interval has changed (e.g., a CAM message is received at an interval shorter than the previous interval, or a CAM message is not received at the expected time relative to the last interval), the AS or eNB in ​​the WTRU can trigger an indication for the eNB itself.

[0153] The expected number of upcoming intervals (and their corresponding values) in which the CAM intervals will remain the same can trigger an indication to the eNB.

[0154] An indication that the CAM interval has reached its maximum value (1 second) can trigger an indication for the eNB.

[0155] As part of an instruction triggered by the eNB, the WTRU may send one or more of the following information to the eNB: a new scheduling interval for the SPS configuration request; a subframe (i.e., offset) of the SPS resource that should begin with the new scheduling interval; the resource size required for the SPS resource; an index for identifying one of several possible timing offsets for the SPS resource pattern; and / or an identifier for the SPS process that needs to change timing (e.g., in the case of multiple processes being configured).

[0156] Regarding the new scheduling interval requested for SPS configuration, WTRU can provide the eNB with one of the possible SPS cycles initially configured for that eNB. Alternatively, WTRU can provide the eNB with any cycle supported by SPS (predefined or standardized).

[0157] Regarding the index (which can be configured or predefined by the eNB) that identifies one of several possible timing offsets for the SPS resource pattern, the eNB can send a set of permissible offsets with the index in the SPS configuration, and the WTRU can provide offset changes by providing the index corresponding to the desired offset.

[0158] Regarding the identifier of an SPS process whose timing needs to be changed (e.g., in the case of multiple processes being configured), such an identifier can be generated by sending an index that references an index provided by the eNB during the configuration of multiple SPS processes. Alternatively, such an identifier can be generated by sending an index corresponding to the order of SPS licenses associated with a specific frame / subframe combination (e.g., SFN x mod y, subframe 0).

[0159] The indication can be sent by the WTRU to the eNB using one of the following methods: a new MAC CE; a new special BSR that retains the information given above; an SR that can be sent on a resource predefined to notify the eNB of the event, and subsequently transmitted using either a BSR or a MAC CE; a PUCCH that can be sent on a resource predefined to notify the eNB of the event; a new MAC CE sent within the SPS resource itself; a RACH or similar transmission performed by the WTRU on the next available RACH resource; or an RRC message.

[0160] After transmitting the instruction to the eNB, the WTRU can continue to transmit CAM using the existing SPS configuration until it receives an acknowledgment from the eNB. Alternatively, if acknowledgment is not expected, the WTRU can change the SPS resources used for CAM transmission to a new configuration at any start time instance as described above (that is, the SPS is implicitly changed based on the transmission instruction).

[0161] Figure 6 This is a message flow diagram for an exemplary embodiment. Figure 6In this context, the WTRU access layer may receive message 602 from the application layer when either trigger condition (1) or (2) as described below occurs. According to condition (1), the elapsed time since the last CAM generation is equal to or greater than T_GenCam_Dcc, and one of the following conditions related to the dynamics of the ITS-S is given: the absolute difference between the current direction of travel of the originating ITS-S and the direction of travel contained in the CAM previously transmitted by the originating ITS-S exceeds 4°; the distance between the current position of the originating ITS-S and the position contained in the CAM previously transmitted by the originating ITS-S exceeds 4 meters; or the absolute difference between the current speed of the originating ITS-S and the speed contained in the CAM previously transmitted by the originating ITS-S exceeds 0.5 m / s. Here, T_GenCam_Dcc provides the minimum time interval between two consecutive CAM generation processes in order to reduce CAM generation processes according to the channel usage requirements of Distributed Congestion Control (DCC). According to condition (2), the time elapsed since the last CAM generation is equal to or greater than T_GenCam, and equal to or greater than T_GenCam_Dcc. Here, T_GenCam represents the current valid upper limit of the CAM generation interval.

[0162] A trigger from an application or entity used to manage vehicle dynamics indicates that the speed, direction, or position has changed from a state where the trigger condition (1) is effective to a state where condition (1) is invalid.

[0163] Once it is determined that the SPS interval needs to change from interval I1 to interval I2 (e.g., once a message from the application layer is received upon the occurrence of triggering condition (1) or (2), the WTRU access layer can send a MAC CE 604 to the eNB containing I2 and the subframe (i.e., the new offset timing) that the RAN expects to be used to send the next CAM message. Subsequently, the WTRU can be scheduled to dynamically schedule resources, or an SR can be sent to trigger such dynamic resource scheduling, and the dynamically scheduled resources can be used to send any pending CAM messages. At some point after the indication using the MAC CE, the WTRU access layer can be scheduled on the PDCCH using the SPS C-RNTI. Once this scheduling is received on the PDCCH, the WTRU can assume that the SPS configuration will change and that the scheduling interval of the SPS is I2. Accordingly, the WTRU can also change the corresponding configuration element in the RRC.

[0164] Figure 7An exemplary embodiment is shown that can shorten the time required for the eNB to signal an SPS change. Upon the occurrence of a triggering condition (e.g., condition (1) or (2) as described above), the WTRU access layer can receive message 702 from the application layer. Once it is determined that the SPS interval needs to be changed from interval I1 to interval I2 704, the WTRU access layer can send a new special BSR 706, wherein the BSR includes interval I2 and the subframe that the access layer expects to be used to send the next CAM message (i.e., the new offset timing). Once an ACK associated with the MAC Protocol Data Unit (PDU) that transmitted the special BSR is received, the WTRU can assume that the SPS configuration has been changed according to the request. Accordingly, the WTRU can also change the corresponding configuration element in the RRC.

[0165] In another exemplary embodiment, the WTRU access layer can receive a message from the application layer or an upper layer indicating that the CAM message periodicity has changed (e.g., from 1 second to 200 milliseconds). Upon receiving this information, the WTRU access layer can send a MAC CE, which contains an identifier of the SPS configuration whose period should be changed and the new period required by the SPS configuration. The WTRU can continue using the current SPS configuration until it receives a new SPS configuration from the eNB (e.g., via an RRC message). Once the new SPS configuration is received, the WTRU can cancel the current SPS configuration and only enable the new SPS configuration after receiving a PDCCH message (e.g., DCI format 5 for sidelinks) encoded with the SPS C-RNTI associated with the new SPS configuration.

[0166] WTRUs can also release specific resources (e.g., a subset of SPS resources) by sending indications, messages, and / or notifications. For example, a WTRU can release a specific set of SPS resources associated with an SPS configuration, rather than the entire configuration, by sending a message to the eNB. As an example, a WTRU can indicate that it does not need (does not intend to use) the SPS resources associated with the next X SPS scheduling intervals. Doing so allows the eNB to schedule these resources to other WTRUs. After the X scheduling intervals, the WTRU can again assume that it can access the SPS resources based on the existing SPS configuration.

[0167] The WTRU may use one of the following methods to send an indication for releasing a specific resource: a new MAC CE; a new special BSR that retains the information given above; an SR that may be sent on a resource predefined to notify the eNB of the event, which may then transmit the aforementioned information using a BSR or MAC CE; a PUCCH that may be sent on a resource predefined to notify the eNB of the event; a new MAC CE sent within the SPS resource itself; a RACH or similar transmission performed by the WTRU on the next available RACH resource; or an RRC message.

[0168] Multiple SPS configurations can be provided. Specifically, multiple SPS configurations and configuration activation / deactivation processes are provided here, which can be dynamically executed in real time based on conditions and triggering events. For example, a WTRU can be configured to have multiple SPS configurations, but only one configuration is active at a given time. The WTRU can then request to change (cycle) between one configuration and one or more other configurations by deactivating the currently active configuration and activating another configuration.

[0169] The WTRU can receive multiple configurations and RRC connection reconfiguration messages from the eNB. The WTRU can receive information about the active configuration for the provided configuration from the eNB. Alternatively, the WTRU may assume that no configuration is active and instead indicate to the eNB later which configuration to activate. The WTRU can send an identifier associated with the SPS configuration to the eNB in ​​an SPS activation / deactivation message to activate or deactivate the corresponding SPS configuration.

[0170] The WTRU can use one of the following methods to send configuration activation / deactivation messages or indicators: a new MACCE; a new special BSR indicating activation / deactivation of the configuration; an SR that can be sent on a resource predefined to notify the eNB of the event; a PUCCH that can be sent on a resource predefined to notify the eNB of the event, wherein the specific PUCCH resource selected by the WTRU can also indicate the SPS configuration to be activated or deactivated; a RACH or similar transport performed by the WTRU on the next available RACH resource; an RRC message; or an SRS-like message, wherein the location of the SRS can potentially indicate the SPS configuration to be activated or deactivated. Furthermore, the location of the SR can also indicate which SPS configuration is activated / deactivated.

[0171] Once an activation / deactivation message is transmitted, the WTRU can consider the requested configuration to be activated. Alternatively, the WTRU can consider the requested configuration to be activated once the eNB responds with: a Hybrid Automatic Repeat Request (HARQ) ACK for a MAC PDU carrying a MAC CE, an explicit RRC message, or a PHY layer message (e.g., a PDCCH message (e.g., a PDCCH with SPS C-RNTI)).

[0172] In this embodiment, the WTRU can activate one SPS configuration while deactivating others by sending a new MAC CE. The activation can take effect in the subframe where the WTRU receives an SPS C-RNTI from the eNB.

[0173] Based on triggers from higher layers, WTRU may use the aforementioned mechanism to disable all SPS configurations. For example, WTRU may receive (e.g., from the adaptation layer) an instruction not to use SPS.

[0174] Triggering conditions for requesting SPS configuration changes include: the application layer, adaptation layer, or upper layer indicating when the traffic period has changed (e.g., from 1 second to 100 milliseconds, or vice versa); the application layer, adaptation layer, or upper layer indicating that the timing (offset) has changed, what the new offset is, and that the timing has changed by a certain amount (e.g., more than a threshold); and WTRU determining, based on information provided by the application layer, adaptation layer, or upper layer, that one configuration is superior to the others.

[0175] Figure 8 Several application-level triggering events related to V2X communication are illustrated. For example, when a vehicle switches from human driver to electronic driving control, an autonomous mode change 802 will be detected. For the WTRU, it would be ideal to allocate a higher (or lower) SPS cycle, thereby allocating more system bandwidth for the autonomous vehicle to send / receive information accordingly. The same applies to the driver under 18 instruction 804. Another illustrative triggering event includes system performance changes, which may be related to firmware software upgrades for the vehicle or WTRU. In some cases, software updates may be frequent. Adding new software or applications can also lead to system performance changes.

[0176] This document provides a logical channel prioritization process for SPS licensing. Specifically, when performing a transmission using a license associated with a specified SPS configuration, the WTRU can select data from logical channels to transmit using that license. The process of selecting data to be transmitted from logical channels can be based on a combination of the following criteria that can be prioritized in any order: transmitting data with the highest PPP priority; transmitting data in descending PPP priority order; transmitting data with a periodicity matching, less than, or greater than the periodicity associated with the SPS configuration of the license; transmitting data based on the configured higher-layer data / services or the mapping between logical channels and SPS configurations; delaying data transmission until a license for the associated SPS configuration is received; and until the next license associated with a particular SPS configuration. Such selections can be applied whether the WTRU has multiple SPS configurations active simultaneously or a single active SPS configuration.

[0177] In one example, the WTRU can select SPS resources for transmitting data originating from higher layers based on the SPS configuration derived from the eNB. The WTRU can receive SPS configurations associated with one or more logical channels, logical channel groups, radio bearers, PPPP, or QCI, etc.

[0178] WTRU can use SPS licenses for SPS configurations associated with logical channels to transmit data from one or more logical channels, etc.

[0179] Alternatively, if the permission allows the transmission of additional data, and the permission can be used to transmit all data in the buffer for the associated logical channel, then the WTRU can first transmit all data from the associated logical channel, and then transmit any remaining data (possibly from other logical channels not associated with the SPS configuration).

[0180] Furthermore, before transmitting any data from the configured logical channels, the WTRU may transmit all data with a priority (e.g., PPP or Logical Channel Group (LCG) priority (i.e., LCP)) higher than that associated with the SPS configuration. Alternatively, the WTRU may consider all data associated with the SPS configuration before considering data with a higher priority (e.g., PPP or LCG priority).

[0181] In another example, the WTRU can determine which SPS resource to use based on the periodicity and / or allocation size of the configured SPS resource, as well as information derived from the application layer. In this case, the WTRU can determine the required transmission interval for a particular application layer packet based on application layer information included with that packet. This information can take the form of parameters similar to QCI, indicating the periodicity and timing requirements attached to the packet. Furthermore, it can be provided to the WTRU in the form of PPPP, where a specific PPPP can be used to indicate data (e.g., CAM traffic) with a specific transmission period.

[0182] When selecting data to be transmitted on an SPS resource, WTRU can identify the period associated with the SPS configuration associated with a specific SPS resource; select upper-layer PDUs that need to match the periodicity so that they can be multiplexed into MAC PDUs for transmission; if all data from the configuration period is already included, select upper-layer PDUs that need a lower periodicity so that they can be multiplexed into MAC PDUs for transmission; and if all of the above are included, select upper-layer PDUs for any periodicity, or select upper-layer PDUs that are not associated with any specific periodicity or timing requirement so that they can be multiplexed into MAC PDUs for transmission.

[0183] In another example, the WTRU can defer the selection of an RLC PDU for transmission until a grant is granted from the associated (configured or based on a mapping determined by the WTRU) SPS configuration, and only select the PDU upon receiving that grant. In this case, during the selection of an RLC PDU for transmission of a MAC PDU, the WTRU can avoid selecting an RLC PDU from a logical channel (regardless of its priority) and can select an RLC PDU from the next highest (in terms of priority) logical channel for transmission. If the arrival time of the next grant for the associated SPS configuration is less than a pre-configured threshold, the WTRU can further avoid selecting the PDU. Otherwise, the WTRU can be configured to use a conventional mechanism (e.g., using the current grant via a conventional grant request mechanism) to transmit packets.

[0184] This section provides processing for managing concurrent SPS licenses. Specifically, the WTRU can be configured to have multiple active SPS configurations so that licenses from different SPS configurations occur simultaneously. This can include licenses occurring on the same UL subframe (for UL SPS transmissions) or the same scheduling period (e.g., for side-link (SL) SPS transmissions). SLSPS refers to the SPS configured for device-to-device (D2D) communication.

[0185] In one example, a WTRU configured with concurrent SPS permissions may need to, or expect to, use only one permission to perform a transport. This could happen, for instance, if the eNB assumes the WTRU will only use one of the configured permissions and allocates UL resources to other WTRUs. The permission a WTRU chooses to use can be selected based on any of the following criteria.

[0186] The selected license may have the largest allocated resources (e.g., in terms of resource blocks). The resource size allocated to the selected license is closest to the size of the data the WTRU will transmit (e.g., the data transmitted in the BSR used by that WTRU). In this scenario, the license may also need to be greater than or equal to the amount of data the WTRU will transmit or that the WTRU indicates in the BSR. The selected license may have optimal channel properties (e.g., based on measurements made by the WTRU or eNB). The selected license may be one that the WTRU detects (e.g., by sensing) as having minimal interference from other WTRUs performing transmissions, or one with minimal overlap (in terms of resources) with transmission resources selected by other WTRUs in the same scheduling period.

[0187] In this example, the WTRU can further use the Logical Channel Priority (LCP) rules discussed above to select the data to be transmitted on the configured and selected licenses.

[0188] In another example, a WTRU configured with concurrent SPS licenses may need or expect to perform transmissions on all licenses within a specified scheduling period or UL subframe. In this case, the WTRU may further use the LCP rules as described above to select data for transmission on concurrent licenses. In this case, the WTRU may perform LCP while conforming to any of the following rules.

[0189] For example, the WTRU can consider the sum of the license sizes of concurrently occurring licenses as the available license size for transmitting MAC PDUs, and can perform LCP given the sum of the license sizes. Alternatively, the WTRU can select licenses for transmitting RLC PDUs, thus eliminating the need to segment the RLC PDUs. Alternatively, the WTRU can consider each license individually and apply the aforementioned LCP rules. For example, the WTRU can select RLC PDUs solely from the logical channels associated with the SPS configuration for transmission within the configured SPS licenses.

[0190] The WTRU can indicate when a specific license will not be used, enabling the eNB to perform reallocation even when multiple SPS licenses are configured. For example, when the WTRU is configured to have multiple licenses and only use a subset (e.g., one) of the SPS licenses configured in a particular subframe, the WTRU can be configured to indicate to the eNB which license it will not use, allowing the eNB to reallocate resources to another device. In one example, the WTRU can first determine which license it will use and then signal (e.g., using a physical channel or other channel) the SPS license it will use (e.g., using an index). The eNB can then determine which SPS licenses(s) are not used based on this information, and thus, the eNB can allocate resources to another device. This approach is particularly advantageous when multiple SPS licenses are configured and the WTRU uses only one SPS license. In another example, the WTRU can be configured to have two SPS licenses, and the WTRU can indicate the SPS license index of the SPS license it does not intend to use (e.g., the SPS license will be cancelled). To ensure effectiveness, this indication may need to be transmitted at a specific time before the actual SPS license is granted.

[0191] This section provides upper-layer auxiliary processing for triggering SPS scheduling assistance. As an example, as described above, the WTRU can receive information from the upper layer (e.g., upper-layer message arrival timing indications, period change indications, timing change indications, upper-layer flagged messages, timing-based information provided by the WTRU to the upper layer, and information related to vehicle dynamic changes). The WTRU can determine, based on the information originating from the upper layer, that it is necessary to send an offset or period change to the eNB. This can correspond to information from the application layer or the adaptation layer, and embodiments thereof will be described below.

[0192] The information received from the upper layer is further described here. Upper-layer information may include message arrival timing indications from the upper layer. For example, the WTRU may receive CAM message arrival indications from the application layer or the upper layer. Such indications are received each time the upper layer sends such a message to the AS.

[0193] Upper-layer information may include indications of period changes. For example, the WTRU may receive changes in the period or interval of CAM messages, as well as indications of new periods for CAM messages, from the application layer or upper layers.

[0194] Upper-layer information may include a timing change indication. For example, the WTRU may receive from the application layer or an upper layer an indication that the timing of a CAM message (or a message requiring SPS alignment) determined by the upper layer has changed. This indication may further include the absolute time of the new timing of the message being transmitted to the lower layer (e.g., the transmission time of an instance of a periodic message stream). Alternatively, the indication may be sent to be consistent with the transmission of a message with the new timing (e.g., the timing of the indicated message represents the timing of that message).

[0195] Upper-layer information may include messages tagged by the upper layer. For example, a CAM message or a message requiring SPS alignment may itself be tagged or indicated by the upper layer. As an example, the message may be tagged with a specific Packet Data Convergence Protocol (PDCP) Service Data Unit (SDU) type for representing the message as requiring SPS alignment. The message may contain a specific PPPP (Packet Priority Per Component) value indicating that the message requires SPS alignment. Furthermore, the message may be received along with other QoS-related information, such as QCI or similar information, where a specific QCI value may indicate a need for SPS alignment and / or timing-related requirements; for example, a specific Packet Delay Budget (PDB) value may represent a delay requirement of 100 milliseconds and / or periodic data.

[0196] The WTRU can be further configured by the eNB to assign all traffic or messages requiring SPS alignment to specific logical channels or radio bearers, etc. This restriction can be based on application layer information, such as QCI or PPPP. As an example, the WTRU can assign all messages with a specific PPPP or QCI indicating the need for SPS alignment to a specific logical channel.

[0197] Upper-layer information may include information based on the timing processes provided by the WTRU to the upper layers. For example, after an SPP is configured by the eNB, the WTRU may provide the configured SPS timing to the upper layers in either of the following ways: the WTRU may provide the upper layers or the application layer with an absolute time instance of the occurrence of one of the SPS resources; and / or the WTRU may provide an indication or signal regarding the presence of such resources on the AS when some or every SPS resource occurs. Furthermore, the application layer may provide the lower layers with an indication that the timing of the currently configured SPS requires a change, as well as additional information needed to create an offset change message for the eNB (e.g., a time shift of the SPS resource or resource pattern required to satisfy the current application layer message generation process).

[0198] Upper-level information may include information related to changes in vehicle dynamics. For example, the AS may receive information related to changes in vehicle dynamics, such as: indications of changes in speed, direction of travel, or acceleration that exceed the event trigger thresholds defined in conditions (1) and (2) described herein; indications that trigger conditions (1) or (2) as described above have occurred; and / or indications that speed, direction, or position has changed from a state where trigger condition (1) is in effect to a state where it is no longer in effect.

[0199] As mentioned above, the CAM size can change periodically, depending on whether the V2X application wants to transmit high-frequency containers, low-frequency containers, or other special containers. Therefore, a fixed SPS allocation is not ideal for providing the resources needed to transmit CAMs. Furthermore, the eNB needs to know the SPS allocation size required for CAM messages, but this information only exists within the WTRU (e.g., in a vehicle).

[0200] Accordingly, the SPS message size can be configured at the application layer. For example, V2X applications on the WRTU can provide size information (e.g., as a CA Basic Service message) to the corresponding applications in the network or located in the eNB via application layer signaling. Size information that can be sent via application layer messages may include: container size; the pattern for sending high-frequency containers, low-frequency containers, or special containers; and / or any dynamic changes in the pattern that occur during operation (e.g., when the V2X WTRU decides to send low-frequency containers at a frequency exceeding the required frequency).

[0201] The application layer located at the network or eNB can provide this information to the eNB in ​​order to define the appropriate SPS allocation size, as well as provide any additional dynamic scheduling for time instances that need to increase the allocated SPS size (e.g., by including additional containers in CAM messages).

[0202] In another example, the SPS message size can be associated with the Quality of Service (QoS) Class Identifier (QCI) of the logical channel. For instance, the required SPS allocation size and potential CAM message size variation patterns may be related to the QCI associated with the V2X logical channel. When establishing a V2X logical channel, the eNB can know or determine the required SPS allocation size (e.g., based on a predefined mapping or from messages obtained from V2X application services in the network) in order to maintain CAM messages.

[0203] The WTRU can indicate the timing and frequency of high-frequency and low-frequency container transmissions by sending synchronization messages to the eNB, so that the WTRU is aware of or determines whether the time instance of the SPS allocation needs to be increased or overridden through dynamic allocation. As an example, this message can indicate the SFN and subframe corresponding to the low-frequency container transmission, and can indicate that the low-frequency container is transmitted every X CAM messages.

[0204] In another example, allocation size changes can be piggybacked onto SPS transmissions. For instance, the WTRU can send a message indicating that the size of the upcoming next CAM message will increase (e.g., it will contain low-frequency containers), and its size may increase compared to the current SPS allocation. Such messages can be piggybacked as MAC CEs within the current CAM message transmission. Compared to dynamic scheduling, this solution has the advantage that the WTRU does not need to send a separate SR or BSR when a larger CAM message arrives, thus avoiding the additional latency (and additional signaling) associated with the SR / BSR method.

[0205] In another example, the SPS allocation size can increase periodically. For instance, a WTRU can be configured to have an SPS allocation that periodically increases after exceeding the resource allocation specified by the PDCCH with the SPS C-RNTI. The resource allocation increase can be fixed (e.g., always twice the SPS allocation) or can be determined by the WTRU based on signaling received from the eNB. For example, the SPS configuration itself in the RRC signaling can include details of the SPS resource allocation increase, its frequency, and the relationship between additional resource elements and regular SPS allocations. In another example, the PDCCH with the SPS C-RNTI itself can indicate (possibly by using a new DCI) the SPS allocation increment and the frequency of this increase, as well as the actual time-frequency location of the increased allocation.

[0206] This document presents an adaptation layer for managing CAM messages using SPS. V2X applications that manage the construction and transmission of CAM messages (as well as other V2X messages such as Basic Security Messages (BSM) or Distributed Environment Notification Messages (DENM)) can interact with different types of transports (e.g., sidelinks and Uu) such as LTE and Dedicated Short Range Communication (DSRC). Since latency requirements must be met regardless of the transport used, from an implementation perspective, the optimal approach is to build an adaptation layer that allows V2X applications to interact with specific transports while meeting the latency requirements of V2X messages, without adding transport-layer-specific information to the V2X application itself.

[0207] The adaptation layer for V2X to LTE can provide the following functions regarding SPS: enabling / disabling SPS based on whether vehicle dynamics justify its use; and providing information to the AS to determine the cycle and timing of SPS traffic. It should be noted that, depending on the specific implementation of the WTRU or the application layer residing on the WTRU, the functions described for the adaptation layer may also reside within the AS or the application layer.

[0208] For enabling / disabling SPS for CAM traffic, the adaptation layer can send an indication to the lower layer indicating when configuring SPS is advantageous (e.g., when CAM traffic is relatively periodic). The WTRU can also send this indication to the eNB to allow / disable the use of SPS (as described above).

[0209] The adaptation layer can determine the use of SPS (i.e., allow / disallow use) based on vehicle dynamics or other information provided by the application layer, such as: whether the vehicle speed is higher than a certain threshold (thus indicating highway driving), the proximity of the vehicle to other vehicles traveling in the same or opposite direction, the vehicle's Global Positioning System (GPS) information, the type of road the WTRU is traveling on, and / or traffic information (e.g., the number of vehicles in the area around the vehicle or in the direction of the vehicle's travel).

[0210] Based on the above information, the adaptation layer can determine the periodicity level of CAM messages generated by the V2X application layer and can send an indication to the lower layers in WTRU regarding whether SPS should be configured.

[0211] In another example, during the same decision-making process as defined above, the adaptation layer can provide instructions to a similar adaptation layer residing in the network. Such an adaptation layer in the network can then provide this information (e.g., for a specific WTRU) directly to the eNB.

[0212] To determine the SPS periodicity, the LTE adaptation layer can receive instantaneous vehicle speeds from the application layer. These speeds can be provided to the adaptation layer periodically. Alternatively, the LTE adaptation layer can receive a new speed or trigger a change in speed exceeding a certain threshold. The adaptation layer can determine the required SPS period and inform the AS layer of the required period based on a simple lookup table. For example, when the speed range is from y11 to y12, the configured period could be x1; when the speed range is from y21 to y22, the configured period could be x2, and so on.

[0213] To determine the SPS timing, the LTE adaptation layer can receive triggers (i.e., trigger conditions (1) and (2)) from the application layer corresponding to the CAM generation process described above. That is, the absolute difference in the direction of travel exceeds a threshold (e.g., 4°), the distance exceeds a threshold (e.g., 4 meters), and / or the speed change exceeds a threshold (e.g., 0.5 m / s). Such triggers can be received from the application layer with separate signaling (e.g., side information) or can be included in the CAM message itself.

[0214] The AS can provide frame and subframe timing to the LTE adaptation layer using any of the following methods: signals or events transmitted for each subframe or interval or subframe; frame and subframe counters maintained by the AS and accessible to the LTE adaptation layer; and / or a function provided by the AS to convert absolute time (maintained on the WTRU) into frame and subframe time. The LTE adaptation layer can maintain precise timing associated with the current SPS configuration based on its previously enabled SPS on the AS. This precise timing can be maintained based on either absolute time or frame / subframe timing. Alternatively, the LTE adaptation layer can receive the absolute time (e.g., configured by the eNB) of the currently configured SPS configuration and the current configured period from the AS. Based on this information, the LTE adaptation layer can calculate the timing for each SPS resource in a timely manner.

[0215] Compensation for AS latency is provided here. As an example, the adaptation layer can provide the desired SPS timing for the AS. Such timing can include compensation for AS latency (e.g., the time from the generation of the CAM message to the preparation time for over-the-air transmission). This compensation factor can be provided dynamically by the AS. The compensation factor can be determined by the LTE adaptation layer using a static value associated with the desired latency. For example, if the maximum given latency is 100 milliseconds, then the LTE adaptation layer can be configured with a compensation factor of size 10 milliseconds to account for the AS latency. This compensation factor can be determined by the LTE adaptation layer based on the capabilities of the WTRU, network, etc., which can be provided in the Subscriber Identity Module (SIM) card, in the WTRU storage / configuration, by the AS after establishing a network connection, and / or by the network as part of the application layer or NAS layer.

[0216] While features and elements in specific combinations have been described above, those skilled in the art will recognize that each feature can be used alone or in any combination with other features and elements. Furthermore, the methods described herein can be implemented in computer programs, software, or firmware incorporated into a computer-readable medium for execution by a computer or processor. Examples of computer-readable media include electrical signals (transmitted via 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, buffer memory, semiconductor storage devices, magnetic media such as internal hard disks and removable disks, magneto-optical media, and optical media such as CD-ROM discs and digital multipurpose discs (DVDs). The processor associated with the software can be used to implement a radio frequency transceiver used in a WTRU, UE, terminal, base station, RNC, or any computer host.

Claims

1. A method performed by a first wireless transmit / receive unit (WTRU), the method comprising: Send a message to the base station, wherein the message indicates the service periodicity, the transport block size, and the timing offset of subframe number 0 relative to system frame number (SFN) 0; Receive from the base station an index identifying the sidelink semi-static scheduling (SPS) configuration and an indication of one or more parameters associated with the sidelink SPS configuration; and The first WTRU transmits data to the second WTRU in a sidelink channel transmission according to the sidelink SPS configuration, wherein the sidelink SPS configuration is one of a plurality of sidelink SPS configurations associated with the first WTRU.

2. The method according to claim 1, wherein, The timing offset indicates the time value relative to subframe number 0 of SFN 0.

3. The method according to claim 1, wherein, The timing offset is indicated in milliseconds.

4. The method according to claim 1, comprising: Instructions regarding the sidelink SPS configuration are received via the Physical Downlink Control Channel (PDCCH).

5. The method according to claim 1, wherein, The data is transmitted according to logical channel priority (LCP).

6. The method of claim 1, further comprising receiving an indication of the sidelink SPS configuration via a Radio Resource Control (RRC) message.

7. A first wireless transmit / receive unit (WTRU), the WTRU including a processor and a memory, the WTRU being configured to: Send a message to the base station, in which, The message indicates the service periodicity, transport block size, and timing offset relative to subframe number 0 of system frame number (SFN) 0; Receive from the base station an index identifying the sidelink semi-static scheduling (SPS) configuration and an indication of one or more parameters associated with the sidelink SPS configuration; as well as The first WTRU transmits data to the second WTRU in a sidelink channel transmission according to the sidelink SPS configuration, wherein the sidelink SPS configuration is one of a plurality of sidelink SPS configurations associated with the first WTRU.

8. The first WTRU of claim 7, wherein the timing offset indicates a time value relative to subframe number 0 of SFN 0.

9. The first WTRU of claim 7, wherein the timing offset is indicated in milliseconds.

10. The first WTRU of claim 7, wherein the processor and memory are further configured to receive instructions regarding the sidelink SPS configuration via the physical downlink control channel (PDCCH).

11. The first WTRU of claim 7, wherein the data is transmitted according to logical channel priority (LCP).

12. The first WTRU of claim 7, wherein the processor and memory are further configured to receive indications regarding the sidelink SPS configuration via Radio Resource Control (RRC) messages.

13. A base station including a processor and a memory, configured as follows: Receive a message from the WTRU, wherein the message indicates the service periodicity, the transport block size, and the timing offset relative to subframe number 0 of system frame number (SFN) 0; Determine multiple side-link semi-persistent scheduling (SPS) configurations associated with the WTRU, each side-link SPS configuration being associated with one or more corresponding side-link transmission parameters and a corresponding index; and Configuration information is transmitted to the WTRU, the configuration information indicating each of the plurality of corresponding side-link SPS configurations and each of the plurality of corresponding indices.

14. The base station according to claim 13, wherein, The timing offset indicates the time value relative to subframe number 0 of SFN 0.

15. The base station according to claim 13, wherein, The timing offset is indicated in milliseconds.

16. The base station according to claim 13, wherein, At least one of the multiple sidelink SPS configurations is determined based on the service periodicity, the transport block size, and the timing offset indicated in the message received from the WTRU.

17. The base station according to claim 16, wherein, The at least one sidelink SPS configuration, including its SPS periodicity, SPS offset, and resource block allocation, is determined based on the service periodicity, transport block size, and timing offset indicated in the message received from the WTRU.

18. The base station according to claim 13, wherein, The processor and memory are also configured to send indications about the sidelink SPS configuration via Radio Resource Control (RRC) messages.

Images