Search

EP-4736552-A1 - DEVICE-TO-DEVICE (D2D) RESOURCE RESERVATION

EP4736552A1EP 4736552 A1EP4736552 A1EP 4736552A1EP-4736552-A1

Abstract

According to an aspect, there is provided a method performed by a first user equipment (UE) (301). The method comprises: transmitting (701) application data to a second UE (303) via a device-to-device (D2D) connection using a first D2D transmission resource (401; 502; 601); and Transmitting (703), to the second UE (303), an indication of one or more second D2D transmission resources (403, 404; 503, 504; 607, 609) useable by the second UE (303) to transmit video traffic to the first UE (301).

Inventors

  • LEON CALVO, Jose Angel
  • KANG, DU HO
  • SRINIVASAN, Nithin
  • SHAPIN, Alexey
  • DE LAVAL, Fabian

Assignees

  • Telefonaktiebolaget LM Ericsson (publ)

Dates

Publication Date
20260506
Application Date
20230630

Claims (20)

  1. 1. A method performed by a first user equipment, UE, (301) the method comprising: transmitting (701) application data to a second UE (303) via a device-to-device, D2D, connection using a first D2D transmission resource (401 ; 502; 601); and transmitting (703), to the second UE (303), an indication of one or more second D2D transmission resources (403, 404; 503, 504; 607, 609) useable by the second UE (303) to transmit video traffic to the first UE (301).
  2. 2. A method as claimed in claim 1 , wherein the D2D transmission resources are time and/or frequency resources.
  3. 3. A method as claimed in claim 1 or 2, wherein the first D2D transmission resource (401 ; 502; 601) and the one or more second D2D transmission resources (403, 404; 503, 504; 607, 609) are resources from a shared resource pool (501).
  4. 4. A method as claimed in claim 1 or 2, wherein the first D2D transmission resource (401 ; 502; 601) is a resource from a first resource pool (402; 603), and the one or more second D2D transmission resources (403, 404; 503, 504; 607, 609) are resources from a second resource pool (405; 605) that is separate from the first resource pool (402; 603).
  5. 5. A method as claimed in any of claims 1-4, wherein the indication is an indication of a defined time and/or frequency relationship of the one or more second D2D transmission resources (403, 404; 503, 504; 607, 609) to the first D2D transmission resource (401 ; 502; 601).
  6. 6. A method as claimed in any of claims 1-5, wherein the indication indicates one or more second D2D transmission resources (403, 404; 503, 504; 607, 609) useable by the second UE (303) after each transmission of application data to the second UE (303).
  7. 7. A method as claimed in any of claims 1-5, wherein the indication indicates one or more second D2D transmission resources (403, 404; 503, 504; 607, 609) useable by the second UE (303) after a plurality of transmissions of application data to the second UE (303).
  8. 8. A method as claimed in any of claims 1-7, wherein the application data is periodically transmitted to the second UE (303).
  9. 9. A method as claimed in any of claims 1-8, wherein the one or more second D2D transmission resources (403, 404; 503, 504; 607, 609) comprises a primary second D2D transmission resource (403; 503; 607) that is a first time period after the first D2D transmission resource (401; 502; 601).
  10. 10. A method as claimed in claim 9, wherein the first time period is determined or set according to one or more of: (i) an expected computation time for the video traffic; (ii) characteristics of the second UE (303); and (iii) a UE implementation of the second UE (303).
  11. 11. A method as claimed in claim 9 or 10, wherein the one or more second D2D transmission resources (403, 404; 503, 504; 607, 609) comprises a secondary second D2D transmission resource (404; 504; 609) that is a second time period after the primary second D2D transmission resource (403; 503; 607).
  12. 12. A method as claimed in claim 11, wherein the second time period is determined or set according to one or more of: (i) a jitter and/or uncertainty in a time required to generate the video traffic; (ii) a delayed computation time for the video traffic; and (iii) a time required for the second UE (303) to receive feedback on a transmission to the first UE (301).
  13. 13. A method as claimed in claim 11 or 12, wherein the method further comprises: receiving the video traffic from the second UE (303) in one of the indicated primary second D2D transmission resource (403; 503; 607) and the indicated secondary second D2D transmission resource (404; 504; 609).
  14. 14. A method as claimed in any of claims 1-8, wherein the method further comprises: receiving the video traffic from the second UE (303) in one of the indicated second D2D transmission resources (403, 404; 503, 504; 607, 609).
  15. 15. A method as claimed in claim 14, wherein the method further comprises: sending a negative acknowledgement, NACK, to the second UE (303) if video traffic is not received in the second D2D transmission resource (403, 404; 503, 504; 607, 609).
  16. 16. A method as claimed in any of claims 1-15, wherein the indication of the one or more second D2D transmission resources (403, 404; 503, 504; 607, 609) is transmitted with the application data.
  17. 17. A method as claimed in any of claims 1-15, wherein the indication of the one or more second D2D transmission resources (403, 404; 503, 504; 607, 609) is transmitted in a control channel for the D2D connection.
  18. 18. A method as claimed in claim 17, wherein the indication is transmitted in Sidelink Control Information, SCI.
  19. 19. A method as claimed in any of claims 1-18, wherein the indication of one or more second D2D transmission resources (403, 404; 503, 504; 607, 609) useable by the second UE (303) to transmit video traffic to the first UE (301) is a bitmap or a binary indication.
  20. 20. A method as claimed in any of claims 1-19, wherein the application data is data representing any of: orientation of the first UE (301) or a user device associated with the first UE (301); position of the first UE (301) or a user device associated with the first UE (301); location of the first UE (301) or a user device associated with the first UE (301); a gaze direction of a user of the first UE (301); control inputs to the first UE (301) or a user device associated with the first UE (301).

Description

Device-to-Device (D2D) resource reservation Technical Field This disclosure relates to reservation of resources for device-to-device (D2D), e.g. sidelink, transmissions, for example transmissions relating to extended Reality (XR) and Cloud Gaming (CG) use cases. The 3rd Generation Partnership Project (3GPP) specified support in Long Term Evolution (LTE) for Proximity Services (ProSe) in Releases 12 and 13, targeting public safety use cases (e.g. first responders) as well as a small subset of commercial use cases (e.g. discovery). The main novelty of ProSe was the introduction of device-to-device (D2D) communications using the sidelink (SL) interface. During Release (Rel-) 14 and Rel-15 in 3GPP, major changes were introduced to the LTE SL framework with the aim of supporting (V2X) communications, where V2X (vehicle-to-everything or vehicle-to-anything) collectively denotes communication between a vehicle to any other endpoint (e.g. a vehicle, a pedestrian, etc.). The feature targeted mostly basic V2X use cases such as day-1 safety, etc. During Rel-16, 3GPP worked on specifying the sidelink interface for the 5th Generation (5G) New Radio (NR). The NR sidelink in Rel-16 mainly targets advanced V2X services, which can be categorised into four use case groups: vehicles platooning, extended sensors, advanced driving and remote driving. The advanced V2X services require a new sidelink in order to meet the stringent requirements in terms of latency and reliability. The NR sidelink is designed to provide higher system capacity and better coverage, and to allow for an easy extension to support the future development of further advanced V2X services and other related services. Given the targeted V2X services by NR sidelink, it is commonly recognised that groupcast/multicast and unicast transmissions are desired, in which the intended receiver of a message consists of only a subset of the vehicles in proximity of the transmitter (groupcast) or of a single vehicle (unicast). For example, in the platooning service there are certain messages that are only of interest to the members of the platoon, making the members of the platoon a natural groupcast. In another example, the see-through use case most likely involves only a pair of vehicles, for which unicast transmissions naturally fit. Therefore, NR sidelink not only supports broadcast as in LTE sidelink, but also groupcast and unicast transmissions. Like in LTE sidelink, the NR sidelink is designed in such a way that its operation is possible with and without network coverage, and with varying degrees of interaction between the User Equipments (UEs) and the NW (network), including support for standalone, network-less operation. In Rel-17, 3GPP is working on multiple enhancements for the sidelink with the aim of extending the support for V2X and to cover other use cases (UCs) such as public safety (as described in 3GPP submission RP-193231). Among these, improving the performance of power limited UEs (e.g., pedestrian UEs, first responder UEs, etc.) and improving the performance using resource coordination are considered critical. For Rel-18, high level discussions regarding non-V2X vertical use cases for sidelink have begun. While the details of the procedures are still under discussion, some examples of use cases that involve sidelink or some form of direct-link between devices are: In-vehicle communications, Industrial Internet of Things (loT), personal loT such as wearables and drones. During Rel-18, the main objectives that will be discussed for sidelink in Rel-18 involve the use of SL in unlicensed spectrum and the design of the beam management procedure for SL in Frequency Range 2 (FR2). For the case of SL in unlicensed spectrum, 3GPP is going to develop mechanisms that enable the operation of SL communications in unlicensed spectrum, sometimes referred to as SL-unlicensed (SL-U) mainly included mechanism to enable the listen-before-talk (LBT) operation needed in the unlicensed spectrum. It is expected that SL-U design will take NR SL and NR-unlicensed (NR-U) designs as baseline. For the case of SL in FR2, the main objective is to design a beam management procedure which is suitable for the SL framework while reusing the mechanisms used for the Uu link as much as possible. The beam management for SL in FR2 is restricted to unicast communications. Resource allocation for sidelink transmissions SL resource pool - Radio resources for SL communication are organised into a SL resource pool. An NR SL resource pool consists of radio resources spanning both the time and frequency domain. In the time domain, the SL resource pool consists of NR slots indexed in an ascending order, starting from index 0 up to a maximum index value. Once this maximum index is reached, the slot indexing starts again from index 0, and so on. In the frequency domain, a resource pool is divided into multiple subchannels (or sub-bands), each subchannel consists of a number of contiguous resourc