Device-to-device (D2D) resource reservation

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).

Description

[0001] Device-to-Device (D2D) resource reservation

[0002] Technical Field

[0003] 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.

[0004] The 3rdGeneration 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.

[0005] During Rel-16, 3GPP worked on specifying the sidelink interface for the 5thGeneration (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.

[0006] 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.

[0007] 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.

[0008] Resource allocation for sidelink transmissions

[0009] 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 resource blocks. A transmission in the sidelink uses an integer number of subchannels.

[0010] Modes of resource allocation for NR SL - There are two resource allocation modes in NR sidelink: Mode 1 and Mode 2. Mode 1 refers to network-scheduled sidelink transmissions while Mode 2 refers to the scenario in which each UE autonomously selects resources for its sidelink transmissions. In Mode 1 the gNB (the base station in NR) schedules a UE via dynamic grants or configured grants. Mode 2 is the more relevant mode of resource allocation for this disclosure, and further details of Mode 2 are provided below. Mode 2 resource allocation is based on sensing of radio resources. The resource selection protocol performed by a UE comprises three parts: sensing within a sensing window, excluding resources reserved by other UEs to find a set of candidate resources, and selecting the transmission resources among the candidate resources within a selection window. It should be noted that resources for transmissions are selected from the set of candidate resources in a random manner, with some extra condition on the minimum time interval between two consecutive selected resources. Additionally, shortly before transmitting in a reserved resource, the UE can re-evaluate the set of reserved resources to take into account the latest status of resource usage (e.g. some of the resources might have been occupied by an aperiodic transmission after the resource reservation). If the reserved resources would not be part of the set for selection at this time, then new resources are selected from an updated resource selection window. In addition to the re-evaluation, pre-emption is also introduced such that a UE selects new resources even after it announces the resource reservation when it observes resource collision with a higher priority transmission from another UE.

[0011] Some details of the sensing windows and selection windows are as follows:

[0012] Resource sensing is performed by decoding the sidelink control information (SCI) sent by other UEs and measuring the received power (e.g. Reference Signal Received Power (RSRP)) at the resource blocks of interest, thereby enabling the exclusion of resources reserved by other UEs. The sensing window is a time window which ends shortly before the resource selection is triggered.

[0013] The selection window starts shortly after the trigger for resource (re-)selection and cannot be longer than the remaining latency budget (also known as packet delay budget (PDB)) of the packet to be transmitted. The procedure for resource selection and resource reselection are the same.

[0014] Fig. 1 illustrates a timeline of the sensing window and the selection window. The sensing and resource (re-)selection procedure in Fig. 1 is triggered at time n. The first reserved resource is at time m. Fig. 1 corresponds to Figure 6.3.2.2-2(a) in 3GPP TR 37.985 v16.0.0. The sensing window consists of SL slots in the period of [n-To, n-Tpr0c,o] and the selection window consists of SL slots in the periods of [n+T1 , n+T2], TO, T1 , T2 and Tpr0c,o are (pre-)configured values satisfying various conditions. The resource re-evaluation can happen at time m-T3 at the latest, where T3 is 2 milliseconds (ms).

[0015] Resource reservation and resource reselection - As described above, when a resource selection is triggered, the UE will select resources for its transmissions. In NR SL Rel-16, the UE is allowed to select multiple resources (up to 32). In each transmission, the UE can signal to other UEs its reservation of up to two additional resources in the near future, and potentially a reservation for periodic transmissions using the same frequency resources in the further future. It should be noted that this means the UE can internally select more resources than it can reserve. Fig. 1 illustrates a case in which, by the transmission at a first selected resource at time m, the UE reserves resources for two additional transmissions. Typically, when the UE performs resource selection, the first selected resource is for the initial transmission of a packet, and the additional reserved resources are for the retransmissions of the same packet.

[0016] The resource re-evaluation and pre-emption described earlier allows a UE to reselect a selected resource if the UE detects that the selected resource (whether a resource that can be reserved or is not-yet-reserved) is occupied by some other UEs with higher priority.

[0017] Physical sidelink channels

[0018] In NR SL, different physical sidelink channels are defined.

[0019] Physical Sidelink Control Channel (PSCCH): The PSCCH is used to carry (part of) sidelink control information (SCI), which is also referred to as the first stage SCI or SC11. The first stage SCI carries the resource allocation information that is essential to decode for performing sensingbased resource allocation (i.e. mode-2).

[0020] Physical Sidelink Shared Channel (PSSCH): The PSSCH is used to carry actual data transmissions. In addition, a part of the SCI, also referred to as the second stage SCI or SCI2, is carried over the PSSCH.

[0021] Physical Sidelink Feedback Channel (PSFCH): The PSFCH is used to carry the Hybrid Automatic Repeat Request (HARQ) feedback information such as HARQ Acknowledgements (ACK) (HARQ-ACK) or HARQ Negative ACKs (NACK) (HARQ-NACK). In Rel-16, only sequence based PSFCH is supported.

[0022] Physical Sidelink Broadcast Channel (PSBCH): The PSBCH is used to carry the system information (SI) which is used to perform sidelink transmissions.

[0023] Sidelink Control Information (SCI) formats

[0024] In NR SL, the Sidelink Control Information (SCI) is divided into two different stages. The first stage (denoted in the 3GPP Specifications as SCI Format 1-A, often referred to as SC11) is included in the PSCCH, and the second stage (which two different formats are denoted in the specifications as SCI-2A and SCI-2B, often commonly referred to as SCI2) is carried by PSSCH. The format of each of the stages is defined in 3GPP TS 38.212 v17.5.0 sections 8.3 and 8.4 respectively.

[0025] The first stage SCI carries some key information such as time and frequency domain resource allocation, Modulation and Coding Scheme (MCS), as well as the indication of the second stage SCI format. This first stage SCI is decodable by all the UEs supporting SL as it is intended for resource reservation and sensing. The second stage SCI further provides additional information such as HARQ process number, New Data Indicator (NDI), Redundancy Version (RV), and source and destination Identities (IDs). To be able to receive PSSCH correctly, the Receiving / Receiver (Rx) UE needs to successfully receive both the first stage SCI and the corresponding second stage SCI correctly.

[0026] Configuration, pre-configuration, and predefinition of parameters

[0027] To operate sidelink, different parameters are used. These parameters may be provided to a UE in different ways:

[0028] • The parameters may be configured by a network node (e.g., a gNB). Configuration may be received using dedicated or broadcast signalling, for example using a System Information Block (SIB) or Radio Resource Control (RRC) signalling. This is typically used when the UE is in coverage of a gNB for a given frequency.

[0029] • The parameters may be preconfigured in the UE. In this case, the pre-configuration is stored in the UE, typically in the Subscriber Identity Module (SIM) card. This is typically used when the UE is not in coverage for a given frequency.

[0030] • The parameters may be predefined or defined in a specification.

[0031] In this disclosure, the term (pre-)configuration includes any of configuration and preconfiguration.

[0032] Extended Reality and Cloud Gaming

[0033] The extended Reality (XR) and Cloud Gaming (CG) use cases and services are getting more popular, attracting a lot of investments in the market, and thus, they are considered very important for 5G NR in Rel-18 and beyond. In general, XR and CG are wide terms referring to various types of augmented, virtual, and mixed environments, where human-to-machine and human-to-human communications are performed with the assistance of handheld and wearable end user devices (UEs).

[0034] In general, Cloud Gaming (CG) refers to the group of use cases where the overwhelming majority of computations related to gaming (single-player or multi-player) is offloaded from the UE or user-held and / or user-worn device to edge or remote server(s).

[0035] In general, extended Reality (XR) is an umbrella term for multiple heterogeneous use cases and services, that were studied and outlined in 3GPP SA1 , SA2, and SA4, including 3GPP TR 22.842, 3GPP TR 26.928, 3GPP TR 26.998, etc. These XR use cases can be roughly divided into: (i) augmented reality (AR); (ii) virtual reality (VR), and (iii) mixed reality (MR). While XR and CG present a set of attractive use cases for future mobile systems, they also impose a set of challenges for mobile networks such as 5G NR that need to be addressed.

[0036] Many of the XR and CG use cases are characterised by quasi-periodic traffic (with possible jitter) with high data rate in downlink (DL) (i.e. video stream) combined with the frequent uplink (UL) (i.e. pose / user control update) and / or UL video stream. Both DL and UL traffic are also characterised by a relatively strict packet delay budget (PDB).

[0037] Many of the end user XR and CG devices are expected to be mobile and of small-scale, thus having limited battery power resources. Therefore, additional power enhancements may be needed to reduce the overall UE power consumption when running XR and CG services and thus extend the effective UE battery lifetime.

[0038] The set of anticipated XR and CG services has a certain variety and characteristics of the data streams (i.e. video) may change “on-the-fly” while the services are running over NR. Therefore, additional information on the running services from higher layers are beneficial for efficient network operation. The most recent work has been done in Rel-18 by the 3GPP SA2 group which studied architecture enhancement for XR and media services capturing results in 3GPP TR 23.700-60. In parallel to SA2 work, the 3GPP RAN1 and 3GPP RAN2 groups studied potential XR Enhancements for NR. Results and conclusions will be captured in 3GPP TR 38.835.

[0039] Potential for sidelink communication - VR Head-Mounted Displays (HMDs) are already available at scale on the market today, but they are rapidly evolving. Because VR applications are often processing-intensive, enabling high-end VR requires connecting the HMDs to high-end processing units - typically powerful personal computers (PCs) or gaming consoles. VR HMDs with local processing capabilities are also starting to become available, but these are relatively large and heavy and cannot provide the same experience as when off-device processing is used.

[0040] AR HMDs are also available on the market today, predominantly for enterprise use. Massmarket adoption will require further progress on ease of use, attractive appearance and content availability. Building fashionable, small form factor HMDs to meet the demands for XR is challenging due to limited processing power, storage, battery life and heat dissipation. The best way to address these challenges is by offloading parts of XR processing to the mobile network edge or / and to another device which can be in proximity of the XR device.

[0041] There are very many options for how XR devices can be connected to an application server and how compute offload can be realised.

[0042] Fig. 2 illustrates some examples of XR device connectivity. It can be seen in Fig. 2 that there are cases when an XR device is connected to a local compute hub or user portable device, which are in turn connected to an application server via the Internet. Here, sidelink communication has a great potential to replace existing cable / Wi-Fi / proprietary links because of the following benefits:

[0043] • SL is a wireless technology meaning that removing a wire improves user experience significantly.

[0044] • SL is based on 3GPP technology which provides tools for End-to-End (E2E) Quality of Service (QoS).

[0045] • SL can use both licensed and shared spectrum.

[0046] • SL can be controlled by gNB scheduling which can do proper planning of transmissions and ensure QoS fulfilment.

[0047] • In case of internet connectivity via 3GPP public or private dedicated network, device cost can be optimised as the same chip / antenna is used for SL and network connectivity.

[0048] XR awareness - In both uplink and downlink, XR-Awareness contributes to optimisations of gNB radio resource scheduling and relies at least on the notions of Protocol Data Unit (PDU) Set and Data Burst (as described in 3GPP TR 23.700-60). A PDU Set is composed of one or more PDUs carrying the payload of one unit of information generated at the application level (e.g. a frame or video slice), while a Data Burst is a set of data PDUs generated and sent by the application in a short period of time.

[0049] The following information may be provided by the CN to RAN (see TR 23.700-60) to assist the handling of QoS flows and PDUs:

[0050] • Semi-static information for both UL and DL provided via control plane (the NG Application Protocol (NGAP)): o Periodicity for UL and DL traffic of the QoS Flow via Time Sensitive Communications (TSC) Assistance Information (TSCAI) / TSC Assistance Container (TSCAC); o Traffic jitter information (e.g. jitter range) associated with each periodicity of the QoS flow; o PDU Set QoS parameters:

[0051] ■ PDU Set Error Rate (PSER): defines an upper bound for the rate of PDU Sets that have been processed by the sender of a link layer protocol but that are not successfully delivered by the corresponding receiver to the upper layer (as described in 3GPP TR 23.700-60).

[0052] ■ PDU Set Delay Budget (PSDB): time between reception of the first PDU and the successful delivery of the last arrived PDU of a PDU Set (as described in 3GPP TR 23.700-60). PSDB is an optional parameter.

[0053] ■ PDU Set Integrated Indication (PSII) i.e. whether all PDUs are needed for the usage of PDU Set by application layer. o Dynamic information for DL provided by user plane (General Packet Radio Service (GPRS) Tunnelling Protocol-User (GTP-U) header):

[0054] ■ PDU Set Sequence Number;

[0055] ■ PDU Set Size in bytes;

[0056] ■ PDU Sequence Number (SN) within a PDU Set;

[0057] ■ End PDU of the PDU Set;

[0058] ■ PDU Set Importance: this parameter is used to identify the importance of a PDU Set within a QoS flow. The Radio Access Network (RAN) may use it for PDU Set level packet discarding in presence of congestion;

[0059] ■ End of Data Burst indication in the header of the last PDU of the Data Burst (optional).

[0060] For the uplink XR traffic, the UE needs to be able to identify PDU Set and Data Bursts dynamically, but in-band marking over Uu of PDUs is not needed.

[0061] When a certain number of PDUs of a PDU Set are known to be required by the application layer to use the corresponding unit of information (for instance due to the absence or limitations of error concealment techniques, see 3GPP TR 26.926), as soon as the number of PDUs known to be lost exceeds this number, the remaining PDUs of that PDU Set are no longer needed by the application and may be subject to a discard operation.

[0062] Relevant Capacity enhancements - In order to enhance the scheduling of uplink resources for XR, the following improvements are envisioned in Rel-18:

[0063] One or more additional Buffer Status (BS) table(s) to reduce the quantisation errors in Buffer Status Report (BSR) reporting (e.g. for high bit rates);

[0064] Delay knowledge of buffered data, consisting of e.g. remaining time, and distinguishing how much data is buffered for which delay. It is to be determined whether the delay information is reported as part of BSR or as a new Medium Access Control (MAC) Control Element (CE). Also, how the delay information can be up to date considering e.g. scheduling and transmission delays needs to be investigated further.

[0065] Additional BSR triggering conditions to allow timely availability of buffer status information can be investigated further.

[0066] Delivery of some assistance information (e.g. periodicity) reusing TSCAI as a baseline. Whether an additional mechanism is required can be further considered with an assumption that all information may not be always available at UE application.

[0067] For Packet Data Convergence Protocol (PDCP) discard operation in uplink, the timer-based discard operation (when configured) should apply to all Service Data Units (SDUs) / PDUs belonging to the same PDU Set. Furthermore, when, for a PDU Set, the number of PDlls known to either be lost or associated to discarded SDlls exceeds a threshold, all remaining PDlls of that PDU Set could be discarded at the transmitter to free up radio resources. This means that the granularity of the discard operation at PDCP in the transmitter should be the PDU Set.

[0068] In uplink, the usage of Configured Grant brings potential benefits for XR services with the enhancements recommended, while in downlink, the usage of Semi-Persistent Scheduling (SPS) is not foreseen to bring any benefits.

[0069] Summary

[0070] There currently exist certain challenge(s). In legacy SL autonomous resource allocation operation, the resources to be used for the upcoming transmissions are selected randomly among the free resources (i.e. based on the sensing operation) within a defined maximum time budget, i.e. a packet delay budget (PDB). This approach is suitable for transmissions which have a somehow ‘loose’ timing relationship / bundling among different transmissions. However, in the case of XR traffic, the uplink pose traffic (i.e. location and / or spatial awareness) and the downlink video traffic are linked together, i.e. the timing between both packets (pose and video) is really stringent in order for the XR application to work successfully. For instance, if the pose and the video traffic are not transmitted within a certain timing constraint, the information will be successfully transmitted but will no longer be useful at the end user / application. Moreover, the video traffic is related to the information transmitted / generated by the pose traffic. The same applies to CG traffic, where the uplink user control inputs and the downlink video traffic are linked together (i.e. the video in the video traffic is generated responsive to the user’s control inputs), and there are tight timing constraints so that the game feels responsive to the user’s inputs.

[0071] Due to this stringent requirement on the CG / XR traffic, it might be difficult to find resources which are suitable for the video traffic - which typically has a bigger payload than the control input / pose traffic - based on the legacy mechanism for reservation of resources. Based on this, a mechanism to protect and obtain a higher likelihood of successful transmission of the video traffic is desired.

[0072] Another existing issue with the CG / XR video traffic is the uncertainty created by the computational operations at the device associated with this type of traffic. Therefore, it is desirable for a mechanism to be defined within the resource allocation procedure to take this aspect into account.

[0073] Therefore, for CG / XR traffic, it is desirable for the resource allocation procedure in D2D (e.g. SL) to be enhanced / optimised to take into consideration the bundle and tight timing between both the user input / pose traffic and the associated video traffic. Certain aspects of the disclosure and their embodiments may provide solutions to these or other challenges. In particular, this disclosure provides enhancements to the autonomous resource allocation procedure for CG / XR traffic to create a tighter bundle between the user input / pose and video traffic in order to provide a high likelihood of correctly receiving both packets.

[0074] In addition, a pairing is defined between the (typically periodic) pose / user input traffic transmission and the associated video traffic transmissions so that resources are reserved for the video traffic transmissions.

[0075] According to a first aspect, there is provided a method performed by a first user equipment (UE), the method comprising: transmitting application data to a second UE via a device-to-device (D2D) connection using a first D2D transmission resource; and transmitting, to the second UE, an indication of one or more second D2D transmission resources useable by the second UE to transmit video traffic to the first UE.

[0076] According to a second aspect, there is provided a method performed by a first user equipment (UE), the method comprising: transmitting application data to a second UE via a device-to-device (D2D) connection using a first D2D transmission resource; and monitoring one or more second D2D transmission resources for video traffic transmitted by the second UE.

[0077] According to a third aspect, there is provided a method performed by a second user equipment (UE) the method comprising: receiving application data from a first UE via a device- to-device (D2D) connection using a first D2D transmission resource; and receiving, from the first UE, an indication of one or more second D2D transmission resources useable by the second UE to transmit video traffic to the first UE.

[0078] According to a fourth aspect, there is provided a method performed by a second user equipment (UE) the method comprising: receiving application data from a first UE via a device- to-device (D2D) connection using a first D2D transmission resource; and transmitting video traffic to the first UE via the D2D connection using one or more second D2D transmission resources.

[0079] According to a fifth aspect, there is provided a computer program product comprising a computer readable medium having computer readable code embodied therein, the computer readable code being configured such that, on execution by a suitable computer or processor, the computer or processor is caused to perform the method according to any of the preceding aspects, or any embodiments thereof.

[0080] According to a sixth aspect, there is provided a user equipment (UE) configured to perform the method according to any of the first to fourth aspects, or any embodiments thereof.

[0081] According to a seventh aspect, there is provided a user equipment (UE) comprising a processor and a memory, said memory containing instructions executable by said processor whereby said UE is operative to perform the method according to any of the first to fourth aspects, or any embodiments thereof.

[0082] Certain embodiments may provide one or more of the following technical advantage(s). For example, certain embodiments can use (optionally) periodic application data (i.e. the user input traffic and / or pose traffic) to reserve resources to be used by the video traffic, and this can reduce the likelihood of collisions for the video traffic, which is more costly to transmit and re-transmit due to its higher payload.

[0083] Another advantage provided by certain embodiments is that a tight bundle of the user input / pose and video traffic can be obtained rather than having random timing of the transmissions as in legacy procedures.

[0084] Another advantage is that certain embodiments provide a mechanism to address the uncertainty / jitter inherent to the video traffic in CG / XR due to the computational operation at the server.

[0085] Brief Description of the Drawings

[0086] Some of the embodiments contemplated herein will now be described more fully with reference to the accompanying drawings, in which:

[0087] Fig. 1 illustrates a timeline of a sensing window and a selection window;

[0088] Fig. 2 illustrates some examples of CG / XR device connectivity;

[0089] Fig. 3 is a simplified block diagram illustrating the devices and communications that one or more embodiments relate to;

[0090] Fig. 4 illustrates the reservation / indication of two sets of resources for video traffic;

[0091] Fig. 5 illustrates resources reserved for application data and video traffic from the same resource pool;

[0092] Fig. 6 illustrates the reservation / indication of resources for application data and video traffic in a super-cycle;

[0093] Fig. 7 is a flow chart illustrating a method of operating a first UE according to some embodiments;

[0094] Fig. 8 is a flow chart illustrating another method of operating a second UE according to some embodiments;

[0095] Fig. 9 is a flow chart illustrating another method of operating a first UE according to some embodiments;

[0096] Fig. 10 is a flow chart illustrating another method of operating a second UE according to some embodiments;

[0097] Fig. 11 shows an example of a communication system in accordance with some embodiments; Fig. 12 shows a UE in accordance with some embodiments; and

[0098] Fig. 13 shows a communication diagram of a host communicating via a network node with a UE over a partially wireless connection in accordance with some embodiments.

[0099] Detailed Description

[0100] Some of the embodiments contemplated herein will now be described more fully with reference to the accompanying drawings. Embodiments are provided by way of example to convey the scope of the subject matter to those skilled in the art.

[0101] In this disclosure, a framework is developed to schedule CG / XR traffic - consisting of application data and video traffic - for D2D (e.g. SL) operation in autonomous resource allocation mode, i.e., without network involvement. The application data - which is assumed to be periodic and have a small payload - is used for reserving video traffic resources which have a bigger payload. The application data and video traffic are transmitted in different independent transmissions and bundle, i.e. the video traffic is created based on the application data traffic, and therefore, it is reasonable that only when both sets are received successfully and in a timely manner will the application work effectively.

[0102] Fig. 3 is a simplified illustration of devices and communications that embodiments of this disclosure relate to. As noted above, this disclosure relates to the scheduling of CG / XR traffic in a D2D connection between two UEs. CG / XR traffic comprises application data that is transmitted in the uplink (UL) direction, and video traffic that is transmitted in the downlink (DL) direction.

[0103] Fig. 3 shows a first UE 301 that represents the CG / XR user device, which can be, for example, a smartphone, headset, HMD, VR HMD, AR HMD, etc. In general, however, the first UE 301 can be any type of UE, or device with UE functionality (i.e. a device such as a computer, laptop, tablet, etc. that has components that enable the device to operate as a UE), that is to transmit application data to another UE (the second UE 303) using D2D / sidelink communications, and that receives video traffic from that other UE (second UE 303) using D2D / sidelink communications. The second UE 303 can be any type of UE, or any type of device with UE functionality.

[0104] In the illustrated embodiment, the second UE 303 communicates with the first UE 301 using D2D communications, and the second UE 303 also communicates with a CG / XR processing unit / Application Server (AS) 305. The CG / XR processing unit / AS 305 generates the video traffic, e.g. in response to processing the received application data, and transmits the video traffic to the second UE 303. It will be appreciated that while the communications between the first UE 301 and the second UE 303 are direct, the communications between the second UE 303 and the CG / XR processing unit / AS 305 are typically indirect, with the second UE 303 communicating with one or more base stations (e.g. an eNB or gNB) in a Radio Access Network (RAN) of a mobile telecommunications network, and the CG / XR processing unit / AS 305 (which is typically external to the mobile telecommunications network) being connected to the Core Network (CN) of the mobile telecommunications network.

[0105] In an alternative to the illustrated embodiment, rather than the video traffic being generated by a separate CG / XR processing unit / AS 305, the second UE 303 is the device responsible for generating the video traffic, e.g. in response to processing the application data. In this alternative, the second UE 303 communicates with the first UE 301 to receive the control data and transmit the video traffic using D2D communications. The second UE 303 may or may not have connectivity to a mobile telecommunications network. In these embodiments, the second UE may be any type of UE, or device with UE functionality, that is able to process the application data and generate suitable video traffic. Thus, the second UE 303 can be a device such as a computer, laptop, tablet, etc. that has components that enable the device to operate as a UE, and in particular to communicate using D2D / sidelink.

[0106] As used herein, “application data” refers to data representing any of the orientation, position, location, gaze direction of the first UE 301 and / or the user of the first UE 301. Application data may also or alternatively include data representing control inputs provided (e.g. by the user) to the first UE 301 or to an input device associated with the first UE 301 , for example one or more button presses, trigger actuations, and / or the orientation and / or position of a control device (e.g. a handheld input device) etc. In the case of AR, the application data can be referred to as “pose traffic”. It will be appreciated from the foregoing examples of “application data” that the application data comprises information or data at the application layer in the first UE 301 and second UE 303, and is data generated for or by the CG / XR application that is running on the first UE 301 , and that is used in generating video traffic by the CG / XR application that is running on the second UE 303 or on the CG / XR processing unit / AS.

[0107] As used herein, video traffic refers to data representing a video stream that is transmitted by the second UE 303 to the first UE 301 , and that is to be displayed by the first UE 301 using a suitable display or displayed by a display associated with, or part of, the first UE. The video traffic can comprise a video stream in any suitable resolution and / or frame rate, and be conveyed using any suitable file / container format. The video stream is generated in response to received application data, e.g. new frames of the video are generated in response to information in the application data indicating that the user’s view direction has changed, the user has provided a button press, trigger pull, etc., and / or the user is interacting with an object in a previous video frame.

[0108] While this disclosure refers to sidelink communications, which is a term used by 3GPP for device-to-device (D2D) communications, it will be appreciated that the techniques described herein are generally applicable to other types of D2D communications where resources are to be reserved for particular transmissions.

[0109] Briefly, according to the techniques described herein, the first UE 301 transmits application data to the second UE 303 via a D2D connection using a first D2D transmission resource. In some embodiments, for example as described with reference to Figs. 8 and 9, the first UE 301 also transmits an indication to the second UE 303 of one or more second D2D transmission resources useable by the second UE 303 to transmit video traffic to the first UE 301. Thus, the second D2D transmission resources are explicitly indicated to the second UE 303. In alternative embodiments, for example as described with reference to Figs. 10 and 11 , the first UE 301 does not transmit an indication to the second UE 303, and instead the first UE 301 monitors one or more second D2D transmission resources for video traffic that is transmitted by the second UE. In these embodiments, there is no explicit indication of which resources to use, and instead the first UE 301 and the second 303 ‘expect’ the transmission of the video traffic to occur using a D2D transmission resource with a predetermined relationship to the D2D transmission resource used to transmit the application data.

[0110] Thus, in case the application data has video traffic associated to it, the application data or associated indication will indicate the resources to be used by the video traffic. Since the video traffic and the application data are effectively bundled together (i.e. a subsequent video traffic transmission is responsive to the content of an earlier application data transmission), it is reasonable to know at the point in time of transmitting the application data about the amount of resource and the timeline of the resulting video traffic. Therefore, in the embodiments described below with reference to Figs. 8 and 9, the application data can include, or be accompanied by, an indication of the time / frequency resources to be used by the video traffic associated to it. In particular embodiments, an indication of the resources useable by the second UE 303 to transmit the video traffic can be included in the application data itself, included in the same transmission as the application data (e.g. in a header for the application data), or included in an accompanying transmission, e.g. in a control information transmission (e.g. in SCI). In the embodiments described below with reference to Figs. 10 and 11 , the resources useable by the second UE 303 to transmit the video traffic can be implicit based on the transmission timing and / or frequency of the application data, e.g. the video traffic resources are the same frequency, but a defined time period after the resources used to transmit the application data.

[0111] In either the explicit or implicit embodiments, the resource used for transmission of the application data and the resource reserved / allocated for transmission of the video traffic can be at least a minimum number (X) of time slots after the application data resource, or a minimum amount of time (e.g. Y milliseconds) after the application data resource. The minimum time between the resource used for transmission of the application data and the resource reserved / al located for transmission of the video traffic can be based on the characteristics and / or implementation of the second UE 303 (particularly where the second UE 303 is the device that generates the video traffic). Characteristics of the second UE 303 can refer to the processing capabilities of the second UE 303, e.g. the available central processing unit (CPU) resources and / or hardware for encoding video frames. Implementation of the second UE 303 can refer to how efficiently the available hardware / software in the second UE 303 is used by the application that generates the video traffic and / or the video codec used to encode the video traffic. In more general embodiments, the minimum time between the resource used for transmission of the application data and the resource reserved / al located for transmission of the video traffic can depend on the minimum processing time of the device that generates the video traffic.

[0112] In embodiments where the resources for the video traffic are explicitly indicated by the transmission of the application data or by a transmission accompanying the transmission of the application data, the specific frequency / time resource(s) for the video traffic can be indicated using a bitmap, a binary indication, or any other suitable type of explicit indication.

[0113] As noted, the video traffic has to be timely transmitted with respect to the application data, and it is proposed to explicitly or implicitly indicate suitable resource(s) for the video traffic with the application data transmission. However, due to the computational time at the device that generates the video stream, there is some uncertainty regarding the actual time when the video traffic will be available to be transmitted. Based on this uncertainty or jitter, embodiments of this disclosure propose the reservation / allocation of two or more sets of resources for the video traffic, i.e. a primary resource / primary set and a secondary resource / secondary set.

[0114] The timing of the primary resource / set relative to the transmission of the application data can be based on a ‘usual’ or ‘expected’ time for the computation of the video stream, and the secondary resource / set can be based on a ‘worst case’ scenario (e.g. an expected amount of jitter) for the computation of the video stream.

[0115] In some embodiments, if the video traffic happens to be sent in the primary resource / set, but the transmission fails, the secondary resource / set can be used to retransmit the video traffic. In this case, if the use of HARQ feedback is enabled for the video traffic, the timing of the secondary resource / set with respect to the primary resource / set can be based on a minimum time taken for the second UE 303 to receive HARQ feedback. In this way, if the second UE 303 receives NACK feedback from the first UE 301, the second UE 303 can retransmit the video traffic using the secondary resource / set.

[0116] Alternatively, if the use of HARQ feedback is not enabled for the video traffic (for example if an automatic re-transmission protocol is used), if the video traffic happens to be sent in the primary resource / set, the secondary resource / set can be used to retransmit the video traffic after a certain time has passed.

[0117] In embodiments where the primary resource / set is indicated explicitly, the time / frequency resource locations of the secondary set can also be indicated in that explicit indication, or the resources for the secondary set can be implied from the primary resources / set (e.g. the secondary resource or the secondary set of resources can use the same frequency as the primary resource(s), but be a predetermined time T after the respective primary resource / set).

[0118] The number of resource sets, i.e. potentially more than the primary and secondary sets described above, to be allocated / reserved for the video traffic can be dependent of one or more parameters relating to the resource pool. The parameter(s) relating to the resource pool can comprise any of the Channel Busy Ratio (CBR), the Channel Occupancy Ratio (CR), the type of UEs allowed to use the resources in the resource pool, and / or the type of traffic that can use the resources in the resource pool.

[0119] In some embodiments the number of resource sets, i.e. potentially more than the primary and secondary sets described above, to be allocated / reserved for the video traffic can be dependent on one or more parameters relating to the video traffic. The parameter(s) relating to the video traffic can comprise any of the priority of the transmission, the PDB of the transmission, a number of re-transmissions already performed for that particular transmission. In this latter case, while the multiple resource sets are primarily provided to allow for the video traffic to be transmitted if there is a delay in generating the video traffic, the multiple resource sets can also be used for retransmitting the video traffic in the event that an initial transmission of the video traffic in an earlier resource set fails, and additional resource set(s) can be allocated specifically for that purpose.

[0120] It is noted that, in general, reserving / allocating more than one set of resources for, at best, only one actual video traffic transmission is an overprovisioning of resources, as a peer UE (e.g. the second UE 303) will see both sets of resources reserved. However, due to the uncertainty of the video traffic computational time and the importance of the timely transmission of the video traffic, particularly for a CG / XR application, this overprovision is needed or even desirable. In addition, in order to avoid reserving excessive resources that can be used for types of transmission other than CG / XR video traffic, e.g. legacy SL communication and / or SL positioning, it is possible to (pre-) configure dedicated resource pools for video traffic.

[0121] In some embodiments the first UE 301 and the second UE 303 share the same resource pool (e.g. time / frequency resource pool) for transmitting the application data and video traffic. That is, any given resource in the resource pool could be used by the first UE 301 for transmitting the application data, or used by the second UE 303 for transmitting the video traffic. In other embodiments, the application data and the video traffic can be allocated to different regions of the single resource pool (where the different regions are completely disjoint (i.e. there is no overlap), or there is some overlap between the regions). In other embodiments, there may be two or more resource pools (e.g. relating to different frequency bands), with the first UE 301 using one or more resources in a first resource pool to transmit the application data, and the second UE 303 using one or more resources in the second resource pool to transmit the video traffic.

[0122] In some embodiments, when selecting or allocating resources for the application data and video traffic, the application data can be considered to have a high or highest priority possible, so that resources for the application data are allocated first.

[0123] In some cases the application data is transmitted periodically, similar to legacy periodic SL traffic which is possible in the current framework. Periodic transmission of the application data may be preferred or desirable for CG and / or XR applications, where the pose of the first UE 301 changes often and / or the user is frequently making control inputs. The periodicity of the application data and / or whether this transmission is CG traffic, XR traffic, or CG / XR traffic (i.e. traffic that requires a close association between the uplink application data and the downlink video traffic), can be indicated in control information for the D2D connection, for example in Sidelink Control Information (SCI), e.g. by means of a 1 -bit flag or some other explicit signalling.

[0124] Two example scenarios of the general idea of ‘bundling’ the application data and video traffic as described herein with and without a dedicated resource pool are shown in Figs. 4 and 5 respectively.

[0125] Fig. 4 shows resources used for application data and video traffic transmission in respective different resource pools. The application data is transmitted using resources 401 in a first resource pool 402. In this example, the resources 401 used or reserved for the application data are periodic. Resources 403, 404 for the video traffic are reserved in a second resource pool 405. A primary resource 403 is allocated / reserved for the video traffic with respect to the relevant application data resource 401 . For example, the resource 403 is a configured / pre-configured time after application data resource 401 reserved in the first resource pool 401. Where the application data transmissions / resources 401 are periodic, primary resources 403 can be periodically reserved in the second resource pool 405. These periodic primary resources 403 form the primary resource set.

[0126] A secondary resource 404 is allocated / reserved for the video traffic with respect to a respective primary resource 403. The secondary resource 404 can be reserved a predetermined time after a respective primary resource 403. The amount of time between the primary resource 403 and the secondary resource 404 can be related to the uncertainty and / or jitter in the time taken for the video traffic to be ready for transmission. In some cases, this uncertainty / jitter time can vary per video traffic transmission, as shown by the different uncertainties / jitter in Fig. 4. In some cases, the amount of jitter, or expected amount of jitter can be communicated between the first UE 301 and the second UE 303 in control information (e.g. in SCI). The jitter can be indicated in control information associated with the primary resource / set. Where the application data transmissions / resources 401 and thus primary resources 403 are periodic, secondary resources 404 can be periodically reserved in the second resource pool 405. These periodic secondary resources 404 form the secondary resource set.

[0127] Thus, in some embodiments each resource 403 in the primary set of resources for the video traffic is a configured / pre-configured time after a respective application data resource 401 reserved or used in the first resource pool 402, and each secondary resource 404 in the second set of resources for the video traffic is some time after a respective primary resource 403 in the primary set of resources according to an uncertainty and / or jitter.

[0128] Fig. 5 shows resources used for application data and video traffic transmission being in the same resource pool 501. The application data is transmitted using resources 502 in resource pool 501. In this example, the resources 502 used or reserved for the application data are periodic. Resources 503, 504 for the video traffic are also reserved in the same resource pool 501. A primary resource 503 is allocated / reserved for the video traffic with respect to the relevant application data resource 502. For example, the primary resource 503 is a configured / pre- configured time after application data resource 502. Where the application data transmissions / resources 502 are periodic, primary resources 503 can be periodically allocated / reserved in the resource pool 501. These periodic primary resources 503 form the primary resource set.

[0129] A secondary resource 504 is allocated / reserved for the video traffic with respect to a respective primary resource 503. The secondary resource 504 can be allocated / reserved a predetermined time after a respective primary resource 503. The amount of time between the primary resource 503 and the secondary resource 504 can be related to the uncertainty and / or jitter in the time taken for the video traffic to be ready for transmission. In some cases, this uncertainty / jitter time can vary per video traffic transmission, as shown by the different uncertainties / jitter in Fig. 5. Where the application data transmissions / resources 502 and thus primary resources 503 are periodic, secondary resources 504 can be periodically allocated / reserved in the resource pool 501. These periodic secondary resources 504 form the secondary resource set.

[0130] Thus, in some embodiments each resource 503 in the primary set of resources for the video traffic is a configured / pre-configured time after a respective application data resource 502, and each secondary resource 504 in the second set of resources for the video traffic is some time after a respective primary resource 503 in the primary set of resources according to an uncertainty and / or jitter.

[0131] It should be noted that while the techniques in this disclosure have been described with respect to two sets of resources for the video traffic, i.e. the primary resource / set and the secondary resource / set, this concept can be extended to more than two sets of resources, according to certain scenarios.

[0132] In some cases, if for a specific application data transmission there is to be no associated video traffic transmitted by the second UE 303 (which can be indicated by explicit signalling in control information, or after decoding and checking a logical channel ID at a MAC layer or in other headers), the first UE 301 does not include any indication of resources allocated / reserved for the transmission of video traffic.

[0133] It will be appreciated that the packet size of the video traffic can be time varying. In this case, not all of the resources reserved / allocated for the video traffic will be used by a particular video traffic transmission. Although the first UE 301 can indicate one or more resources have been reserved / allocated for video traffic, some of the resource(s) can be used by other nearby UEs if the resource(s) are not occupied due to an instantaneously reduced packet size. The nearby UEs can use the unused reserved resource based on local measurements (i.e. a listen- before-talk (LBT) measurement returns a measurement that the resource is available). In some embodiments, a transmitting UE (i.e. the second UE 303) can send an indication of which video traffic transmission is the last transmission using the currently reserved resources. In that case, nearby UEs can detect this explicit indication and identify some currently-reserved resource(s) that will be unused, and then reuse the resource(s) itself. This explicit indication can be 1-bit signalling in a Physical Cell Identity (PCI), or a special separate physical Radio Network Temporary Identifier (RNTI). In embodiments where there are primary and secondary resources / sets, resources in either set can be reused / reallocated if there are any resources that are unused.

[0134] In some XR applications, an XR UE (e.g. the first UE 301) can form a ‘communication party’ with another XR UE. In this case the XR UEs can have bi-directional traffic between each other, i.e. both XR UEs generate and stream video traffic and application data to each other. This is known as ‘conversational XR’. One example of this is two users with respective XR head mounted devices in the same room playing a video game, or two users collaboratively working in a virtual environment. In this case, both XR UEs can exchange resource reservation information between them to at least to avoid any potential collisions in a more predictable manner and also reduce sensing (i.e. LBT) overhead. For example, when a first XR UE is in a sensing mode, it can know the resource reservation of the second XR UE so that the first XR UE can avoid sensing the resource reserved for the second XR UE, and thereby save energy. This can be realised if the second XR UE signals information about reserved resources to the first XR UE. This signalling can be by either RRC or MAC CE command. This signalling can also be sent whenever any one of the XR UEs that are communicating needs to change its resource reservation. The signalling of the resource / set change can be also included in a MAC PDU so that it can be delivered together with regular data of the last transmission of the currently selected resource set.

[0135] In the embodiments illustrated in Figs. 4 and 5, there is a one-to-one relationship between application data transmissions and video traffic transmissions (i.e. the transmissions have the same periodicity). That is, for each resource used for transmitting application data, there is a respective resource or resource set for transmitting the video traffic generated from that application data. However, different embodiments are possible. For example, the ‘sampling rate’ of the application data may be higher than the rate at which video traffic is transmitted. That is, there may be multiple transmissions of application data before the resulting video traffic is transmitted. Thus, due to the periodic nature of the application data, several application data transmissions can be associated to the same resource / set to be used for video traffic. In this case, if each application data transmission indicates the resources for the respective video traffic, several of the application data transmissions will indicate the same video traffic resources. As an example, for every 4 application data transmissions, there is one video traffic transmission. In this case, one or multiple primary and secondary resource sets can be triggered upon transmission of one out of X, or all X, application data packets, where X is any positive integer number. This is discussed further below with reference to Fig. 6.

[0136] In another different embodiment, each application data transmission can be followed by several (different) video traffic transmissions. Each application data transmission can indicate the resources for each of the different video traffic transmissions.

[0137] When the periodicity of the application data transmissions is different to the periodicity of the video traffic transmissions and several application data transmissions correspond to several video transmissions, it can be said that there are super-cycles for application data and video traffic transmissions that have an offset to each other. In this case, resources / sets can be reserved based on super-cycles, while each application data / video traffic flow follows its own periodicity within the super-cycle, such that the first application data transmission in the super cycle triggers resources / sets reservation for video traffic transmissions for the complete super cycle. The length of a super cycle can be determined as the smallest divisible number for two periodicities signalled to a UE (e.g. in Time Sensitive Communications Assistance Information (TSCAI)) or determined by a UE. Fig. 6 illustrates the reservation / indication of resources for application data and video traffic in a super-cycle. Fig. 6 shows separate resource pools for the application data 601 (resource pool 603) and video traffic (resource pool 605), with the resources for the video traffic including primary resources 607 and secondary resources 609 as discussed above. In this illustrated example, the periodicity of the application data 601 is 4 milliseconds (ms) and the periodicity of the video traffic 607 / 609 is 33.333ms, so there is a super cycle of 100ms for both streams, i.e. 25 application data 601 transmissions correspond to 3 video traffic transmissions 607 / 609.

[0138] In another embodiment, a XR UE which has application data to transmit can reserve resources for another UE, e.g., a compute UE, in case the XR UE does not have associated video traffic to transmit (e.g. in the case where the XR UE sends application data and video traffic from its own camera, with that video traffic being augmented by the compute UE or server with the XR data). The XR UE can indicate, using dedicated signalling, to the compute UE the set of resources to be used by the compute UE for its video traffic.

[0139] The above mechanism may be triggered based on a request by the compute UE 303 when it has video traffic to transmit. Further, the request can be sent in response to the application data from the XR UE 301 in the form of a feedback, for example HARQ feedback with predefined resources with an additional bit. The application data can also include an indication of whether the XR UE 301 has any video traffic associated with the application data. As a result, the compute UE 303 can decide to either use the primary / secondary resources or resort to a sensing procedure to identify resources to use.

[0140] The compute UE 303 may indicate to the XR UE 301 the processing delay / jitter to be used for the resource reservation. The information regarding the processing delay can be included within the request from the compute UE 303 or sent as a standalone message.

[0141] The above mechanism may be triggered, for example, by the compute UE 303 sending a request in case it does not perform sensing, e.g. due to power saving or not having sensing capability.

[0142] The dedicated signalling indicating the resources to be used by the compute UE 303 may include the identity (ID) of the compute UE 303, e.g. L1-ID or L2-ID, or a dedicated ID for XR traffic. The dedicated signalling may be piggybacked with data that is sent from the XR UE 301 to the compute UE 303.

[0143] Figs 7-10 are flow charts illustrating methods performed by UEs according to various embodiments of the techniques described herein. Any of the methods may be performed by a UE or other wireless device, including the UE 1112 or UE 1200 as described later with reference to Figs. 11 and 12 respectively. The UEs may perform any of the methods in response to executing suitably formulated computer readable code. The computer readable code may be embodied or stored on a computer readable medium, such as a memory chip, optical disc, or other storage medium. The computer readable medium may be part of a computer program product.

[0144] The flow chart in Fig. 7 illustrates a method performed by a first UE 301 and the flow chart in Fig. 8 illustrates a corresponding method performed by a second UE 303. The methods in Figs. 7 and 8 correspond to the ‘explicit’ embodiments described above. The methods relate to D2D transmission resources for application data and video traffic. The application data and video traffic may be for an XR application that is running in the first UE 301 , or for a CG application that is running in the first UE 301 .

[0145] The application data may be data representing any of: orientation of the first UE 301 or a user device (e.g. a VR headset) 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 301or a user device associated with the first UE 301 .

[0146] The video traffic can be video content generated by a second UE 303 or by a computing device (that sends the video traffic to the second UE 303 for the second UE 303 to send to the first UE 301. The video traffic is generated based on application data.

[0147] In step 701 of Fig. 7, the first UE 301 transmits application data to a second UE 303 via a D2D connection using a first D2D transmission resource.

[0148] In step 703 of Fig. 7, the first UE 301 transmits, to the second UE 303, an indication of one or more second D2D transmission resources useable by the second UE to transmit video traffic to the first UE 301.

[0149] In step 801 of Fig. 8, the second UE 303 receives application data from the first UE 301 via a D2D connection using a first D2D transmission resource.

[0150] In step 803 of Fig. 8, the second UE 303 receives an indication the first UE 301 of one or more second D2D transmission resources useable by the second UE 303 to transmit video traffic to the first UE 301.

[0151] The application data may be periodically transmitted to the second UE 303, i.e. steps 701 / 801 can be performed periodically.

[0152] The indication sent in step 703 / received in step 803 associates the application data to the video traffic.

[0153] The indication sent in step 703 / received in step 803 can be transmitted with the application data, i.e. in the same transmission as the application data. Alternatively, the indication sent in step 703 / received in step 803 is transmitted in a control channel for the D2D connection, for example in SCI. The indication sent in step 703 / received in step 803 may indicate the second D2D transmission resource(s) via a bitmap or a binary indication.

[0154] The indication sent in step 703 / received in step 803 can be an indication of a defined time and / or frequency relationship of the one or more second D2D transmission resources to the first D2D transmission resource. For example, the indication can indicate the same or a different frequency for the second D2D transmission resources, a time interval between the first D2D transmission resource and the second D2D transmission resources and / or a number of time slots between the first D2D transmission resource and the second D2D transmission resources.

[0155] The indication sent in step 703 / received in step 803 can indicate one or more second D2D transmission resources useable by the second UE 303 after each transmission of application data to the second UE 303. That is, there can be a one-to-one relationship between application data transmissions and video traffic transmissions. Alternatively, the indication sent in step 703 / received in step 803 can indicate one or more second D2D transmission resources useable by the second UE 303 after a plurality of transmissions of application data to the second UE 303. That is, as shown in Fig. 6, there can be multiple application data transmissions for each video traffic transmission.

[0156] The first D2D transmission resource and second D2D transmission resources can be time and / or frequency resources. The first D2D transmission resource and the one or more second D2D transmission resources may be resources from a shared resource pool. Alternatively, the first D2D transmission resource is a resource from a first resource pool, and the one or more second D2D transmission resources are resources from a second resource pool that is separate from the first resource pool.

[0157] After step 803, the second UE 303 can send the video traffic to the first UE 301 in one of the indicated second D2D transmission resources. Correspondingly, after step 703, the first UE 301 can receive the video traffic from the second UE 303 in one of the indicated second D2D transmission resources.

[0158] In some embodiments, the first UE 301 may be configured to send a NACK to the second UE 303 if video traffic is not received in the second D2D transmission resource.

[0159] After receiving video traffic, the first UE 301 can display the received video traffic on a display screen of the first UE 301 or a display screen of a user device associated with the first UE 301 (e.g. a screen in a VR headset).

[0160] As noted above, if there is uncertainty as to when the video traffic will be ready to be transmitted to the first UE 301 , e.g. due to processing delays / jitter at the device that generates the video traffic, multiple second D2D transmission resources can be provided for the transmission of the video traffic. Therefore, in some embodiments the one or more second D2D transmission resources comprises a primary second D2D transmission resource that is a first time period after the first D2D transmission resource, and a secondary second D2D transmission resource that is a second time period after the primary second D2D transmission resource. The first time period can be 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. The second time period can be 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 to receive feedback on a transmission to the first UE 301 .

[0161] In embodiments where there are primary and secondary D2D transmission resources, the second UE 303 can send the video traffic to the first UE 301 in one of the indicated primary second D2D transmission resource and the indicated secondary second D2D transmission resource. In particular, once the video traffic is available at the second UE 303, the second UE 303 can send the video traffic to the first UE 301 using whichever of the primary second D2D transmission resource and the secondary second D2D transmission resources occurs next in time.

[0162] The flow chart in Fig. 9 illustrates another method performed by a first UE 301 and the flow chart in Fig. 10 illustrates a corresponding method performed by a second UE 303. The methods in Figs. 9 and 10 correspond to the ‘implicit’ embodiments described above. The methods relate to D2D transmission resources for application data and video traffic. The application data and video traffic may be for an XR application that is running in the first UE 301 , or for a CG application that is running in the first UE 301 .

[0163] The application data may be data representing any of: orientation of the first UE 301 or a user device (e.g. a VR headset) 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 301or a user device associated with the first UE 301 .

[0164] The video traffic can be video content generated by a second UE 303 or by a computing device (that sends the video traffic to the second UE 303 for the second UE 303 to send to the first UE 301. The video traffic is generated based on application data.

[0165] In step 901 of Fig. 9, the first UE 301 transmits application data to the second UE 303 via a D2D connection using a first D2D transmission resource.

[0166] In step 903 of Fig. 9, the first UE 301 monitors one or more second D2D transmission resources for video traffic transmitted by the second UE 303.

[0167] In step 1001 of Fig. 10, the second UE 303 receives application data from the first UE 301 via the D2D connection using the first D2D transmission resource. In step 1003 of Fig. 10, the second UE 303 transmits video traffic to the first UE 301 via the D2D connection using one or more second D2D transmission resources.

[0168] The application data may be periodically transmitted to the second UE 303, i.e. steps 901 / 1001 can be performed periodically.

[0169] The one or more second D2D transmission resources have a defined time and / or frequency relationship to the first D2D transmission resource. For example, the defined relationship can be the second D2D transmission resources have the same or a defined different frequency to the first D2D transmission resource, a time interval between the first D2D transmission resource and the second D2D transmission resources and / or a number of time slots between the first D2D transmission resource and the second D2D transmission resources.

[0170] The first D2D transmission resource and second D2D transmission resources can be time and / or frequency resources. The first D2D transmission resource and the one or more second D2D transmission resources may be resources from a shared resource pool. Alternatively, the first D2D transmission resource is a resource from a first resource pool, and the one or more second D2D transmission resources are resources from a second resource pool that is separate from the first resource pool.

[0171] In some embodiments, the first UE 301 monitors all available D2D transmission resources in step 903, but in other embodiments the first UE 301 monitors D2D transmission resources in which video traffic can be expected from the second UE 303.

[0172] As a result of the monitoring in step 903, the first UE 301 can receive video traffic from the second UE 303 in one of the second D2D transmission resources.

[0173] In some embodiments, the first UE 301 may be configured to send a NACK to the second UE 303 if video traffic is not received in the second D2D transmission resource.

[0174] After receiving video traffic, the first UE 301 can display the received video traffic on a display screen of the first UE 301 or a display screen of a user device associated with the first UE 301 (e.g. a screen in a VR headset).

[0175] As noted above, if there is uncertainty as to when the video traffic will be ready to be transmitted to the first UE 301 , e.g. due to processing delays / jitter at the device that generates the video traffic, multiple second D2D transmission resources can be provided for the transmission of the video traffic. Therefore, in some embodiments the one or more second D2D transmission resources comprises a primary second D2D transmission resource that is a first time period after the first D2D transmission resource, and a secondary second D2D transmission resource that is a second time period after the primary second D2D transmission resource. The first time period can be 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. The second time period can be 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 to receive feedback on a transmission to the first UE 301. In these embodiments, the first UE 301 can receive the video traffic from the second UE 303 in one of the monitored primary second D2D transmission resource and the monitored secondary second D2D transmission resource.

[0176] Fig. 11 shows an example of a communication system 1100 in accordance with some embodiments. In the example, the communication system 1100 includes a telecommunication network 1102 that includes an access network 1104, such as a radio access network (RAN), and a core network 1106, which includes one or more core network nodes 1108. The access network 1104 includes one or more access network nodes, such as access network nodes 1110a and 1110b (which are interchangeably referred to as RAN network nodes 1110 herein), or any other similar 3rdGeneration Partnership Project (3GPP) access node or non-3GPP access point (AP). Moreover, as will be appreciated by those of skill in the art, a RAN network node is not necessarily limited to an implementation in which a radio portion and a baseband portion are supplied and integrated by a single vendor. Thus, it will be understood that network nodes include disaggregated implementations or portions thereof. For example, in some embodiments, the telecommunication network 1102 includes one or more Open-RAN (ORAN) network nodes. An ORAN network node is a node in the telecommunication network 1102 that supports an ORAN specification (e.g., a specification published by the O-RAN Alliance, or any similar organization) and may operate alone or together with other nodes to implement one or more functionalities of any node in the telecommunication network 1102, including one or more network nodes 1110 and / or core network nodes 1108.

[0177] Examples of an ORAN network node include an open radio unit (O-RU), an open distributed unit (O-DU), an open central unit (O-CU), including an O-CU control plane (O-CU-CP) or an O- CU user plane (O-CU-UP), a RAN intelligent controller (RIC) (near-real time or non-real time) hosting software or software plug-ins, such as a near-real time control application (e.g., xApp) or a non-real time control application (e.g., rApp), or any combination thereof (the adjective “open” designating support of an ORAN specification). The network node may support a specification by, for example, supporting an interface defined by the ORAN specification, such as an A1 , F1, W1 , E1 , E2, X2, Xn interface, an open fronthaul user plane interface, or an open fronthaul management plane interface. Moreover, an ORAN access node may be a logical node in a physical node. Furthermore, an ORAN network node may be implemented in a virtualization environment (described further below) in which one or more network functions are virtualized. For example, the virtualization environment may include an O-Cloud computing platform orchestrated by a Service Management and Orchestration Framework via an 0-2 interface defined by the O-RAN Alliance or comparable technologies.

[0178] The access network nodes 1110 facilitate direct or indirect connection of wireless devices (also referred to interchangeably herein as user equipment (UE)), such as by connecting UEs 1112a, 1112b, 1112c, and 1112d (one or more of which may be generally referred to as UEs 1112) to the core network 1106 over one or more wireless connections. The access network nodes 1110 may be, for example, access points (APs) (e.g. radio access points), base stations (BSs) (e.g. radio base stations, Node Bs, evolved Node Bs (eNBs) and New Radio (NR) NodeBs (gNBs)).

[0179] Unless otherwise indicated, the general term ‘network node’ as used herein refers to access network nodes 1110 and core network nodes 1108.

[0180] Example wireless communications over a wireless connection include transmitting and / or receiving wireless signals using electromagnetic waves, radio waves, infrared waves, and / or other types of signals suitable for conveying information without the use of wires, cables, or other material conductors. Moreover, in different embodiments, the communication system 1100 may include any number of wired or wireless networks, network nodes, UEs, and / or any other components or systems that may facilitate or participate in the communication of data and / or signals whether via wired or wireless connections. The communication system 1100 may include and / or interface with any type of communication, telecommunication, data, cellular, radio network, and / or other similar type of system.

[0181] The wireless devices / UEs 1112 may be any of a wide variety of communication devices, including wireless devices arranged, configured, and / or operable to communicate wirelessly with the network nodes 1110 and other communication devices. Similarly, the access network nodes 1110 are arranged, capable, configured, and / or operable to communicate directly or indirectly with the UEs 1112 and / or with other network nodes or equipment in the telecommunication network 1102 to enable and / or provide network access, such as wireless network access, and / or to perform other functions, such as administration in the telecommunication network 1102.

[0182] In the depicted example, the core network 1106 connects the access network nodes 1110 to one or more hosts, such as host 1116. These connections may be direct or indirect via one or more intermediary networks or devices. In other examples, network nodes may be directly coupled to hosts. The core network 1106 includes one more core network nodes (e.g. core network node 1108) that are structured with hardware and software components. Features of these components may be substantially similar to those described with respect to the wireless devices / UEs, access network nodes, and / or hosts, such that the descriptions thereof are generally applicable to the corresponding components of the core network node 1108. Example core network nodes include functions of one or more of a Mobile Switching Center (MSC), Mobility Management Entity (MME), Home Subscriber Server (HSS), Access and Mobility Management Function (AMF), Session Management Function (SMF), Authentication Server Function (ALISF), Subscription Identifier De-concealing function (SIDF), Unified Data Management (UDM), Security Edge Protection Proxy (SEPP), Network Exposure Function (NEF), and / or a User Plane Function (UPF).

[0183] The host 1116 may be under the ownership or control of a service provider other than an operator or provider of the access network 1104 and / or the telecommunication network 1102, and may be operated by the service provider or on behalf of the service provider. The host 1116 may host a variety of applications to provide one or more services. In particular, the host 1116 can be a server or other processing device for an XR application and / or a CG application. That is, the host 1116 can receive the application data from the first UE 301 via the second UE 303 and access network 1104, process the application data to generate video traffic, and send the video traffic to the first UE 301 via the access network 1104 and the second UE 303. Examples of other such applications include the provision of live and / or pre-recorded audio / video content, data collection services, for example, retrieving and compiling data on various ambient conditions detected by a plurality of UEs, analytics functionality, social media, functions for controlling or otherwise interacting with remote devices, functions for an alarm and surveillance center, or any other such function performed by a server.

[0184] As a whole, the communication system 1100 of Fig. 11 enables connectivity between the wireless devices / UEs, network nodes, and hosts. In that sense, the communication system may be configured to operate according to predefined rules or procedures, such as specific standards that include, but are not limited to: Global System for Mobile Communications (GSM); Universal Mobile Telecommunications System (UMTS); Long Term Evolution (LTE), and / or other suitable 2ndGeneration (2G), 3rdGeneration (3G), 4thGeneration (4G), 5thGeneration (5G) standards, or any applicable future generation standard (e.g. 6thGeneration (6G)); wireless local area network (WLAN) standards, such as the Institute of Electrical and Electronics Engineers (IEEE) 802.11 standards (WiFi); and / or any other appropriate wireless communication standard, such as the Worldwide Interoperability for Microwave Access (WiMax), Bluetooth, Z-Wave, Near Field Communication (NFC) ZigBee, LiFi, and / or any low-power wide-area network (LPWAN) standards such as LoRa and Sigfox.

[0185] In some examples, the telecommunication network 1102 is a cellular network that implements 3GPP standardized features. Accordingly, the telecommunications network 1102 may support network slicing to provide different logical networks to different devices that are connected to the telecommunication network 1102. For example, the telecommunications network 1102 may provide Ultra Reliable Low Latency Communication (URLLC) services to some UEs, while providing Enhanced Mobile Broadband (eMBB) services to other UEs, and / or Massive Machine Type Communication (mMTC) / Massive Internet of Things (loT) services to yet further UEs.

[0186] In some examples, the UEs 1112 are configured to transmit and / or receive information without direct human interaction. For instance, a UE may be designed to transmit information to the access network 1104 on a predetermined schedule, when triggered by an internal or external event, or in response to requests from the access network 1104. Additionally, a UE may be configured for operating in single- or multi-radio access technology (RAT) or multi-standard mode. For example, a UE may operate with any one or combination of Wi-Fi, NR (New Radio) and LTE, i.e. being configured for multi-radio dual connectivity (MR-DC), such as E-UTRAN (Evolved- UTRA (UMTS Terrestrial Radio Access) Network) New Radio - Dual Connectivity (EN-DC).

[0187] In the example illustrated in Fig. 11 , the hub 1114 communicates with the access network 1104 to facilitate indirect communication between one or more UEs (e.g. UE 1112c and / or 1112d) and access network nodes (e.g. access network node 1110b). In some examples, the hub 1114 may be a controller, router, a content source and analytics node, or any of the other communication devices described herein regarding UEs. For example, the hub 1114 may be a broadband router enabling access to the core network 1106 for the UEs. As another example, the hub 1114 may be a controller that sends commands or instructions to one or more actuators in the UEs. Commands or instructions may be received from the UEs, network nodes 1110, or by executable code, script, process, or other instructions in the hub 1114. As another example, the hub 1114 may be a data collector that acts as temporary storage for UE data and, in some embodiments, may perform analysis or other processing of the data. As another example, the hub 1114 may be a content source. For example, for a UE that is a Virtual Reality VR headset, display, loudspeaker or other media delivery device, the hub 1114 may retrieve VR assets, video, audio, or other media or data related to sensory information via a network node, which the hub 1114 then provides to the UE either directly, after performing local processing, and / or after adding additional local content. In still another example, the hub 1114 acts as a proxy server or orchestrator for the UEs, in particular if one or more of the UEs are low energy Internet of Things (loT) devices.

[0188] The hub 1114 may have a constant / persistent or intermittent connection to the network node 1110b. The hub 1114 may also allow for a different communication scheme and / or schedule between the hub 1114 and UEs (e.g. UE 1112c and / or 1112d), and between the hub 1114 and the core network 1106. In other examples, the hub 1114 is connected to the core network 1106 and / or one or more UEs via a wired connection. Moreover, the hub 1114 may be configured to connect to a Machine-to-Machine (M2M) service provider over the access network 1104 and / or to another UE over a direct connection. In some scenarios, UEs may establish a wireless connection with the network nodes 1110 while still connected via the hub 1114 via a wired or wireless connection. In some embodiments, the hub 1114 may be a dedicated hub - that is, a hub whose primary function is to route communications to / from the UEs from / to the network node 1110b. In other embodiments, the hub 1114 may be a non-dedicated hub - that is, a device which is capable of operating to route communications between the UEs and network node 1110b, but which is additionally capable of operating as a communication start and / or end point for certain data channels.

[0189] Fig. 12 shows a wireless device or UE 1200 in accordance with some embodiments.

[0190] As used herein, a UE refers to a device capable, configured, arranged and / or operable to communicate wirelessly with network nodes and / or other UEs. Examples of a wireless device / UE include, but are not limited to, a smart phone, mobile phone, cell phone, voice over IP (VoIP) phone, wireless local loop phone, desktop computer, personal digital assistant (PDA), wireless camera, gaming console or device, music storage device, playback appliance, wearable terminal device, wireless endpoint, mobile station, tablet, laptop, laptop-embedded equipment (LEE), laptop-mounted equipment (LME), smart device, wireless customer-premise equipment (CPE), vehicle, vehicle-mounted or vehicle embedded / integrated wireless device, etc. Other examples include any UE identified by the 3rd Generation Partnership Project (3GPP), including a narrow band internet of things (NB-loT) UE, a machine type communication (MTC) UE, and / or an enhanced MTC (eMTC) UE.

[0191] A wireless device / UE may support device-to-device (D2D) communication, for example by implementing a 3GPP standard for sidelink communication, Dedicated Short-Range Communication (DSRC), vehicle-to-vehicle (V2V), vehicle-to-infrastructure (V2I), or vehicle-to- everything (V2X). In other examples, a UE may not necessarily have a user in the sense of a human user who owns and / or operates the relevant device. Instead, a UE may represent a device that is intended for sale to, or operation by, a human user but which may not, or which may not initially, be associated with a specific human user (e.g. a smart sprinkler controller). Alternatively, a UE may represent a device that is not intended for sale to, or operation by, an end user but which may be associated with or operated for the benefit of a user (e.g. a smart power meter).

[0192] The UE 1200 includes processing circuitry 1202 that is operatively coupled via a bus 1204 to an input / output interface 1206, a power source 1208, a memory 1210, a communication interface 1212, and / or any other component, or any combination thereof. Certain UEs may utilize all or a subset of the components shown in Fig. 12. The level of integration between the components may vary from one UE to another UE. Further, certain UEs may contain multiple instances of a component, such as multiple processors, memories, transceivers, transmitters, receivers, etc.

[0193] The processing circuitry 1202 is configured to process instructions and data and may be configured to implement any sequential state machine operative to execute instructions stored as machine-readable computer programs in the memory 1210. The processing circuitry 1202 may be implemented as one or more hardware-implemented state machines (e.g. in discrete logic, field-programmable gate arrays (FPGAs), application specific integrated circuits (ASICs), etc.); programmable logic together with appropriate firmware; one or more stored computer programs, general-purpose processors, such as a microprocessor or digital signal processor (DSP), together with appropriate software; or any combination of the above. For example, the processing circuitry 1202 may include multiple central processing units (CPUs). The processing circuitry 1202 may be operable to provide, either alone or in conjunction with other UE 1200 components, such as the memory 1210, to provide UE 1200 functionality. For example, the processing circuitry 1202 may be configured to cause the UE 1202 to perform the methods as described with reference to any of Figs. 8-11.

[0194] In the example, the input / output interface 1206 may be configured to provide an interface or interfaces to an input device, output device, or one or more input and / or output devices. Examples of an output device include a speaker, a sound card, a video card, a display, a monitor, a printer, an actuator, an emitter, a smartcard, another output device, or any combination thereof. An input device may allow a user to capture information into the UE 1200. Examples of an input device include a touch-sensitive or presence-sensitive display, a camera (e.g. a digital camera, a digital video camera, a web camera, etc.), a microphone, a sensor, a mouse, a trackball, a directional pad, a trackpad, a scroll wheel, a smartcard, and the like. The presence-sensitive display may include a capacitive or resistive touch sensor to sense input from a user. A sensor may be, for instance, an accelerometer, a gyroscope, a tilt sensor, a force sensor, a magnetometer, an optical sensor, a proximity sensor, a biometric sensor, etc., or any combination thereof. An output device may use the same type of interface port as an input device. For example, a Universal Serial Bus (USB) port may be used to provide an input device and an output device.

[0195] In some embodiments, the power source 1208 is structured as a battery or battery pack. Other types of power sources, such as an external power source (e.g. an electricity outlet), photovoltaic device, or power cell, may be used. The power source 1208 may further include power circuitry for delivering power from the power source 1208 itself, and / or an external power source, to the various parts of the UE 1200 via input circuitry or an interface such as an electrical power cable. Delivering power may be, for example, for charging of the power source 1208. Power circuitry may perform any formatting, converting, or other modification to the power from the power source 1208 to make the power suitable for the respective components of the UE 1200 to which power is supplied.

[0196] The memory 1210 may be or be configured to include memory such as random access memory (RAM), read-only memory (ROM), programmable read-only memory (PROM), erasable programmable read-only memory (EPROM), electrically erasable programmable read-only memory (EEPROM), magnetic disks, optical disks, hard disks, removable cartridges, flash drives, and so forth. In one example, the memory 1210 includes one or more application programs 1214, such as an operating system, web browser application, a widget, gadget engine, or other application, and corresponding data 1216. The memory 1210 may store, for use by the UE 1200, any of a variety of various operating systems or combinations of operating systems.

[0197] The memory 1210 may be configured to include a number of physical drive units, such as redundant array of independent disks (RAID), flash memory, USB flash drive, external hard disk drive, thumb drive, pen drive, key drive, high-density digital versatile disc (HD-DVD) optical disc drive, internal hard disk drive, Blu-Ray optical disc drive, holographic digital data storage (HDDS) optical disc drive, external mini-dual in-line memory module (DIMM), synchronous dynamic random access memory (SDRAM), external micro-DIMM SDRAM, smartcard memory such as tamper resistant module in the form of a universal integrated circuit card (UICC) including one or more subscriber identity modules (SIMs), such as a Universal Subscriber Identity Module (USIM) and / or integrated SIM (ISIM), other memory, or any combination thereof. The UICC may for example be an embedded UICC (eUlCC), integrated UICC (iUICC) or a removable UICC commonly known as ‘SIM card.’ The memory 1210 may allow the UE 1200 to access instructions, application programs and the like, stored on transitory or non-transitory memory media, to offload data, or to upload data. An article of manufacture, such as one utilizing a communication system may be tangibly embodied as or in the memory 1210, which may be or comprise a device- readable storage medium.

[0198] The processing circuitry 1202 may be configured to communicate with an access network or other network using the communication interface 1212. The communication interface 1212 may comprise one or more communication subsystems and may include or be communicatively coupled to an antenna 1222. The communication interface 1212 may include one or more transceivers used to communicate, such as by communicating with one or more remote transceivers of another device capable of wireless communication (e.g. another UE or a network node in an access network). Each transceiver may include a transmitter 1218 and / or a receiver 1220 appropriate to provide network communications (e.g. optical, electrical, frequency allocations, and so forth). Moreover, the transmitter 1218 and receiver 1220 may be coupled to one or more antennas (e.g. antenna 1222) and may share circuit components, software or firmware, or alternatively be implemented separately.

[0199] In some embodiments, communication functions of the communication interface 1212 may include cellular communication, Wi-Fi communication, LPWAN communication, data communication, voice communication, multimedia communication, short-range communications such as Bluetooth, near-field communication, location-based communication such as the use of the global positioning system (GPS) or other Global Navigation Satellite System (GNSS) to determine a location, another like communication function, or any combination thereof. Communications may be implemented in according to one or more communication protocols and / or standards, such as IEEE 802.11, Code Division Multiplexing Access (CDMA), Wideband Code Division Multiple Access (WCDMA), GSM, LTE, NR, UMTS, WiMax, Ethernet, transmission control protocol / internet protocol (TCP / IP), synchronous optical networking (SONET), Asynchronous Transfer Mode (ATM), QUIC, Hypertext Transfer Protocol (HTTP), and so forth.

[0200] Regardless of the type of sensor, a UE may provide an output of data captured by its sensors, through its communication interface 1212, via a wireless connection to a network node. Data captured by sensors of a UE can be communicated through a wireless connection to a network node via another UE. The output may be periodic (e.g. once every 15 minutes if it reports the sensed temperature), random (e.g. to even out the load from reporting from several sensors), in response to a triggering event (e.g. when moisture is detected an alert is sent), in response to a request (e.g. a user initiated request), or a continuous stream (e.g. a live video feed of a patient).

[0201] As another example, a UE comprises an actuator, a motor, or a switch, related to a communication interface configured to receive wireless input from a network node via a wireless connection. In response to the received wireless input the states of the actuator, the motor, or the switch may change. For example, the UE may comprise a motor that adjusts the control surfaces or rotors of a drone in flight according to the received input or controls a robotic arm performing a medical procedure according to the received input.

[0202] A UE, when in the form of an loT device, may be a device for use in one or more application domains, these domains comprising, but not limited to, city wearable technology, extended industrial application and healthcare. Non-limiting examples of such an loT device are devices which are or which are embedded in: a connected refrigerator or freezer, a TV, a connected lighting device, an electricity meter, a robot vacuum cleaner, a voice controlled smart speaker, a home security camera, a motion detector, a thermostat, a smoke detector, a door / window sensor, a flood / moisture sensor, an electrical door lock, a connected doorbell, an air conditioning system like a heat pump, an autonomous vehicle, a surveillance system, a weather monitoring device, a vehicle parking monitoring device, an electric vehicle charging station, a smart watch, a fitness tracker, a head-mounted display for Augmented Reality (AR) or VR, a wearable for tactile augmentation or sensory enhancement, a water sprinkler, an animal- or item-tracking device, a sensor for monitoring a plant or animal, an industrial robot, an Unmanned Aerial Vehicle (UAV), and any kind of medical device, like a heart rate monitor or a remote controlled surgical robot. A UE in the form of an loT device comprises circuitry and / or software in dependence on the intended application of the loT device in addition to other components as described in relation to the UE 1200 shown in Fig. 12.

[0203] As yet another specific example, in an loT scenario, a UE may represent a machine or other device that performs monitoring and / or measurements, and transmits the results of such monitoring and / or measurements to another UE and / or a network node. The UE may in this case be an M2M device, which may in a 3GPP context be referred to as an MTC device. As one particular example, the UE may implement the 3GPP NB-loT standard. In other scenarios, a UE may represent a vehicle, such as a car, a bus, a truck, a ship and an airplane, or other equipment that is capable of monitoring and / or reporting on its operational status or other functions associated with its operation.

[0204] In practice, any number of UEs may be used together with respect to a single use case. For example, a first UE might be or be integrated in a drone and provide the drone’s speed information (obtained through a speed sensor) to a second UE that is a remote controller operating the drone. When the user makes changes from the remote controller, the first UE may adjust the throttle on the drone (e.g. by controlling an actuator) to increase or decrease the drone’s speed. The first and / or the second UE can also include more than one of the functionalities described above. For example, a UE might comprise the sensor and the actuator, and handle communication of data for both the speed sensor and the actuators.

[0205] Fig. 13 shows a communication diagram of a host 1302, such as a server or other processing device for an XR or CG application, communicating via a network node 1304 with a UE 1306 over a partially wireless connection in accordance with some embodiments. In Fig. 13, UE 1306 corresponds to the first UE 301 described herein, i.e. the UE that receives the video traffic from the host 1302 and displays it to the user of the UE. The second UE 303 that receives the application data from UE 1306, relays that application data to the host 1302, receives the video traffic from the host 1302 and transmits that video traffic to UE 1306 via a D2D or SL connection is not shown in Fig. 6.

[0206] Example implementations, in accordance with various embodiments, of the UE (such as a UE 1112a of Fig. 11 and / or UE 1200 of Fig. 12), access network node (such as RAN network node 1110a of Fig. 11), core network node QQ7, and host (such as host 1116 of Fig. 11) discussed in the preceding paragraphs will now be described with reference to Fig. 13. Embodiments of host 1302 include hardware, such as a communication interface, processing circuitry, and memory. The host 1302 also includes software, which is stored in or accessible by the host 1302 and executable by the processing circuitry. The software includes a host application that may be operable to provide a service to a remote user, such as the UE 1306 connecting via an over-the-top (OTT) connection 1350 extending between the UE 1306 and host 1302. In providing the service to the remote user, a host application may provide user data which is transmitted using the OTT connection 1350.

[0207] The network node 1304 includes hardware enabling it to communicate with the host 1302 and UE 1306. The connection 1360 may be direct or pass through a core network (like core network 1106 of Fig. 11) and / or one or more other intermediate networks, such as one or more public, private, or hosted networks. For example, an intermediate network may be a backbone network or the Internet.

[0208] The UE 1306 includes hardware and software, which is stored in or accessible by UE 1306 and executable by the UE’s processing circuitry. The software includes a client application, such as a web browser or operator-specific “app” that may be operable to provide a service to a human or non-human user via UE 1306 with the support of the host 1302. In the host 1302, an executing host application may communicate with the executing client application via the OTT connection 1350 terminating at the UE 1306 and host 1302. In providing the service to the user, the UE's client application may receive request data from the host's host application and provide user data in response to the request data. The OTT connection 1350 may transfer both the request data and the user data. The UE's client application may interact with the user to generate the user data that it provides to the host application through the OTT connection 1350.

[0209] The OTT connection 1350 may extend via a connection 1360 between the host 1302 and the network node 1304 and via a wireless connection 1370 between the network node 1304 and the UE 1306 to provide the connection between the host 1302 and the UE 1306. The connection 1360 and wireless connection 1370, over which the OTT connection 1350 may be provided, have been drawn abstractly to illustrate the communication between the host 1302 and the UE 1306 via the network node 1304, without explicit reference to any intermediary devices and the precise routing of messages via these devices, such as second UE 303.

[0210] As an example of transmitting data via the OTT connection 1350, in step 1308, the host 1302 provides user data (video traffic), which may be performed by executing a host application. In some embodiments, the user data is associated with a particular human user interacting with the UE 1306. In other embodiments, the user data is associated with a UE 1306 that shares data with the host 1302 without explicit human interaction. In step 1310, the host 1302 initiates a transmission carrying the user data towards the UE 1306. The host 1302 may initiate the transmission responsive to a request transmitted by the UE 1306. The request may be caused by human interaction with the UE 1306 or by operation of the client application executing on the UE 1306. The transmission may pass via the network node 1304, in accordance with the teachings of the embodiments described throughout this disclosure. Accordingly, in step 1312, the network node 1304 transmits to the UE 1306 the user data that was carried in the transmission that the host 1302 initiated, in accordance with the teachings of the embodiments described throughout this disclosure. In step 1314, the UE 1306 receives the user data carried in the transmission, which may be performed by a client application executed on the UE 1306 associated with the host application executed by the host 1302.

[0211] In some examples, the UE 1306 executes a client application which provides user data to the host 1302. The user data may be provided in reaction or response to the data received from the host 1302. Accordingly, in step 1316, the UE 1306 may provide user data, which may be performed by executing the client application. In providing the user data, the client application may further consider user input received from the user via an input / output interface of the UE 1306. Regardless of the specific manner in which the user data was provided, the UE 1306 initiates, in step 1318, transmission of the user data towards the host 1302 via the network node 1304. In step 1320, in accordance with the teachings of the embodiments described throughout this disclosure, the network node 1304 receives user data from the UE 1306 and initiates transmission of the received user data towards the host 1302. In step 1322, the host 1302 receives the user data carried in the transmission initiated by the UE 1306.

[0212] One or more of the various embodiments improve the performance of OTT services provided to the UE 1306 using the OTT connection 1350, in which the wireless connection 1370 forms the last segment. More precisely, the teachings of these embodiments may improve the latency with which video traffic is delivered to UE 1306 and thereby provide benefits such as better responsiveness and improved video content presentation to the user.

[0213] In an example scenario, factory status information may be collected and analysed by the host 1302. As another example, the host 1302 may process audio and video data which may have been retrieved from a UE for use in creating maps. As another example, the host 1302 may collect and analyse real-time data to assist in controlling vehicle congestion (e.g. controlling traffic lights). As another example, the host 1302 may store surveillance video uploaded by a UE. As another example, the host 1302 may store or control access to media content such as video, audio, VR or AR which it can broadcast, multicast or unicast to UEs. As other examples, the host 1302 may be used for energy pricing, remote control of non-time critical electrical load to balance power generation needs, location services, presentation services (such as compiling diagrams etc. from data collected from remote devices), or any other function of collecting, retrieving, storing, analysing and / or transmitting data.

[0214] In some examples, a measurement procedure may be provided for the purpose of monitoring data rate, latency and other factors on which the one or more embodiments improve. There may further be an optional network functionality for reconfiguring the OTT connection 1350 between the host 1302 and UE 1306, in response to variations in the measurement results. The measurement procedure and / or the network functionality for reconfiguring the OTT connection may be implemented in software and hardware of the host 1302 and / or UE 1306. In some embodiments, sensors (not shown) may be deployed in or in association with other devices through which the OTT connection 1350 passes; the sensors may participate in the measurement procedure by supplying values of the monitored quantities exemplified above, or supplying values of other physical quantities from which software may compute or estimate the monitored quantities. The reconfiguring of the OTT connection 1350 may include message format, retransmission settings, preferred routing etc.; the reconfiguring need not directly alter the operation of the network node 1304. Such procedures and functionalities may be known and practiced in the art. In certain embodiments, measurements may involve proprietary UE signalling that facilitates measurements of throughput, propagation times, latency and the like, by the host 1302. The measurements may be implemented in that software causes messages to be transmitted, in particular empty or ‘dummy’ messages, using the OTT connection 1350 while monitoring propagation times, errors, etc.

[0215] Although the computing devices described herein (e.g. UEs, RAN network nodes, core network node, hosts) may include the illustrated combination of hardware components, other embodiments may comprise computing devices with different combinations of components. It is to be understood that these computing devices may comprise any suitable combination of hardware and / or software needed to perform the tasks, features, functions and methods disclosed herein. Determining, calculating, obtaining or similar operations described herein may be performed by processing circuitry, which may process information by, for example, converting the obtained information into other information, comparing the obtained information or converted information to information stored in the network node, and / or performing one or more operations based on the obtained information or converted information, and as a result of said processing making a determination. Moreover, while components are depicted as single boxes located within a larger box, or nested within multiple boxes, in practice, computing devices may comprise multiple different physical components that make up a single illustrated component, and functionality may be partitioned between separate components. For example, a communication interface may be configured to include any of the components described herein, and / or the functionality of the components may be partitioned between the processing circuitry and the communication interface. In another example, non-computationally intensive functions of any of such components may be implemented in software or firmware and computationally intensive functions may be implemented in hardware.

[0216] In certain embodiments, some or all of the functionality described herein may be provided by processing circuitry executing instructions stored on in memory, which in certain embodiments may be a computer program product in the form of a non-transitory computer-readable storage medium. In alternative embodiments, some or all of the functionality may be provided by the processing circuitry without executing instructions stored on a separate or discrete device- readable storage medium, such as in a hard-wired manner. In any of those particular embodiments, whether executing instructions stored on a non-transitory computer-readable storage medium or not, the processing circuitry can be configured to perform the described functionality. The benefits provided by such functionality are not limited to the processing circuitry alone or to other components of the computing device, but are enjoyed by the computing device as a whole, and / or by end users and a wireless network generally.

[0217] The foregoing merely illustrates the principles of the disclosure. Various modifications and alterations to the described embodiments will be apparent to those skilled in the art in view of the teachings herein. It will thus be appreciated that those skilled in the art will be able to devise numerous systems, arrangements, and procedures that, although not explicitly shown or described herein, embody the principles of the disclosure and can be thus within the scope of the disclosure. Various exemplary embodiments can be used together with one another, as well as interchangeably therewith, as should be understood by those having ordinary skill in the art.

Claims

AMENDED CLAIMS [received by the International Bureau on 5 June 2024 (05.06.2024)]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); wherein the video traffic is video content generated by the second UE (303) or a computing device (305) based on the transmitted application data, and wherein a timing of the one or more second D2D transmission resources relative to the transmission of the application data is based on a timing constraint between the video content and transmitted application data.

2. A method as claimed in claim 1 , wherein the D2D transmission resources are time and / or frequency resources.

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. 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. 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. 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).50AMENDED SHEET (ARTICLE 19)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. A method as claimed in any of claims 1-7, wherein the application data is periodically transmitted to the second UE (303).

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) with a timing that is a first time period after the first D2D transmission resource (401; 502; 601).

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. 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) with a timing that is a second time period after the primary second D2D transmission resource (403; 503; 607).

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. 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. A method as claimed in any of claims 1-12, 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).51AMENDED SHEET (ARTICLE 19)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. 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. 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. A method as claimed in claim 17, wherein the indication is transmitted in Sidelink Control Information, SCI.

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. 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).

21. A method as claimed in any of claims 1-20, wherein the application data and video traffic are for an extended Reality, XR, application in the first UE (301) or a Cloud Gaming, CG, application in the first UE (301).

22. A method as claimed in any of claims 1-21 , wherein the method further comprises: displaying the received video traffic on a display screen of the first UE (301) or a display screen of a user device associated with the first UE (301).

23. A method as claimed in any of claims 1-22, wherein the indication associates the application data to the video traffic.52AMENDED SHEET (ARTICLE 19)24. A method performed by a first user equipment, UE, (301) the method comprising: transmitting (901) application data to a second UE (303) via a device-to-device, D2D, connection using a first D2D transmission resource (401 ; 502; 601); and monitoring (903) one or more second D2D transmission resources (403, 404; 503, 504; 607, 609) for video traffic transmitted by the second UE (303); wherein the video traffic is video content generated by the second UE (303) or a computing device (305) based on the transmitted application data, and wherein a timing of the one or more second D2D transmission resources relative to the transmission of the application data is based on a timing constraint between the video content and transmitted application data.

25. A method as claimed in claim 24, wherein the D2D transmission resources are time and / or frequency resources.

26. A method as claimed in claim 24 or 25, 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).

27. A method as claimed in claim 24 or 25, 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).

28. A method as claimed in any of claims 24-27, wherein the application data is periodically transmitted to the second UE (303).

29. A method as claimed in any of claims 24-28, wherein the one or more second D2D transmission resources (403, 404; 503, 504; 607, 609) have a defined time and / or frequency relationship to the first D2D transmission resource (401 ; 502; 601).

30. A method as claimed in any of claims 24-29, 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) with a timing that is a first time period after the first D2D transmission resource (401 ; 502; 601).53AMENDED SHEET (ARTICLE 19)31. A method as claimed in claim 30, 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).

32. A method as claimed in claim 30 or 31, 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) with a timing that is a second time period after the primary second D2D transmission resource (403; 503; 607).

33. A method as claimed in claim 32, 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).

34. A method as claimed in claim 32 or 33, wherein the method further comprises: receiving the video traffic from the second UE (303) in one of the monitored primary second D2D transmission resource (403; 503; 607) and the monitored secondary second D2D transmission resource (404; 504; 609).

35. A method as claimed in any of claims 24-28, wherein the one or more monitored second D2D transmission resources (403, 404; 503, 504; 607, 609) comprise all available D2D transmission resources.

36. A method as claimed in any of claims 24-35, wherein the method further comprises: receiving the video traffic from the second UE (303) in one of the monitored second D2D transmission resources (403, 404; 503, 504; 607, 609).

37. A method as claimed in claim 36, wherein the method further comprises: sending a negative acknowledgement, NACK, to the second UE (303) if video traffic is not received in the monitored one or more second D2D transmission resources (403, 404; 503, 504; 607, 609).

38. A method as claimed in any of claims 24-37, 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 of54AMENDED SHEET (ARTICLE 19)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).

39. A method as claimed in any of claims 24-38, wherein the application data and video traffic are for an extended Reality, XR, application in the first UE (301) or a Cloud Gaming, CG, application in the first UE (301).

40. A method as claimed in any of claims 24-39, wherein the method further comprises: displaying the received video traffic on a display screen of the first UE (301) or a display screen of a user device associated with the first UE (301).

41. A method performed by a second user equipment, UE, (303) the method comprising: receiving (801) application data from a first UE (301) via a device-to-device, D2D, connection using a first D2D transmission resource (401 ; 502; 601); and receiving (803), from the first UE (301), 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); wherein the video traffic is video content generated by the second UE (303) or a computing device (305) based on the received application data, and wherein a timing of the one or more second D2D transmission resources relative to the receipt of the application data is based on a timing constraint between the video content and received application data.

42. A method as claimed in claim 41 , wherein the D2D transmission resources are time and / or frequency resources.

43. A method as claimed in claim 41 or 42, 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).

44. A method as claimed in claim 41 or 42, 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).55AMENDED SHEET (ARTICLE 19)45. A method as claimed in any of claims 41-44, 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).

46. A method as claimed in any of claims 41-45, 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).

47. A method as claimed in any of claims 41-45, 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).

48. A method as claimed in any of claims 41-47, wherein the application data is periodically received from the first UE (301).

49. A method as claimed in any of claims 41-48, 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) with a timing that is a first time period after the first D2D transmission resource (401 ; 502; 601).

50. A method as claimed in claim 49, 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).

51. A method as claimed in claim 49 or 50, 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) with a timing that is a second time period after the primary second D2D transmission resource (403; 503; 607).

52. A method as claimed in claim 51 , 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).

53. A method as claimed in claim 51 or 52, wherein the method further comprises:56AMENDED SHEET (ARTICLE 19)sending the video traffic to the first UE (301) in one of the indicated primary second D2D transmission resource (403; 503; 607) and the indicated secondary second D2D transmission resource (404; 504; 609).

54. A method as claimed in any of claims 41-48, wherein the method further comprises: sending the video traffic to the first UE (301) in one of the indicated second D2D transmission resources (403, 404; 503, 504; 607, 609).

55. A method as claimed in claim 54, wherein the method further comprises: receiving a negative acknowledgement, NACK, from the first UE (301) indicating that video traffic has not been received in the second D2D transmission resource (403, 404; 503, 504; 607, 609).

56. A method as claimed in any of claims 41-55, wherein the indication of the one or more second D2D transmission resources (403, 404; 503, 504; 607, 609) is received with the application data.

57. A method as claimed in any of claims 41-55, wherein the indication of the one or more second D2D transmission resources (403, 404; 503, 504; 607, 609) is received in a control channel for the D2D connection.

58. A method as claimed in claim 57, wherein the indication is received in Sidelink Control Information, SCI.

59. A method as claimed in any of claims 41-58, 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.

60. A method as claimed in any of claims 41-59, 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).57AMENDED SHEET (ARTICLE 19)61. A method as claimed in any of claims 41-60, wherein the application data and video traffic are for an extended Reality, XR, application in the first UE (301) or a Cloud Gaming, CG, application in the first UE (301).

62. A method as claimed in any of claims 41-61 , wherein the indication associates the application data to the video traffic.

63. A method performed by a second user equipment, UE, (303) the method comprising: receiving (1001) application data from a first UE (301) via a device-to-device, D2D, connection using a first D2D transmission resource (401 ; 502; 601); and transmitting (1003) video traffic to the first UE (301) via the D2D connection using one or more second D2D transmission resources (403, 404; 503, 504; 607, 609); wherein the video traffic is video content generated by the second UE (303) or a computing device (305) based on the received application data, and wherein a timing of the one or more second D2D transmission resources relative to the receipt of the application data is based on a timing constraint between the video content and transmitted application data.

64. A method as claimed in claim 63, wherein the D2D transmission resources are time and / or frequency resources.

65. A method as claimed in claim 63 or 64, 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).

66. A method as claimed in claim 63 or 64, 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).

67. A method as claimed in any of claims 63-66, wherein the application data is periodically received from the first UE (301).

68. A method as claimed in any of claims 63-67, wherein the one or more second D2D transmission resources (403, 404; 503, 504; 607, 609) have a defined time and / or frequency relationship to the first D2D transmission resource.58AMENDED SHEET (ARTICLE 19)69. A method as claimed in any of claims 63-68, 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) with a timing that is a first time period after the first D2D transmission resource (401 ; 502; 601).

70. A method as claimed in claim 69, 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).

71. A method as claimed in claim 69 or 70, 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) with a timing that is a second time period after the primary second D2D transmission resource (403; 503; 607).

72. A method as claimed in claim 71 , 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).

73. A method as claimed in any of claims 63-72, wherein the method further comprises: receiving a negative acknowledgement, NACK, from the first UE (301) indicating that video traffic was not received in the one or more second D2D transmission resources (403, 404; 503, 504; 607, 609).

74. A method as claimed in any of claims 63-73, 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).

75. A method as claimed in any of claims 63-74, wherein the application data and video traffic are for an extended Reality, XR, application in the first UE (301) or a Cloud Gaming, CG, application in the first UE (301).59AMENDED SHEET (ARTICLE 19)7Q. A computer program product comprising a computer readable medium having computer readable code embodied therein, the computer readable code being configured such that, on execution by a suitable computer or processor, the computer or processor is caused to perform the method of any of claims 1-75.

77. A user equipment, UE, (301 ; 303; 1112; 1200) configured to perform the method of any of claims 1-75.

78. A user equipment, UE, comprising a processor and a memory, said memory containing instructions executable by said processor whereby said UE is operative to perform the method of any of claims 1-75.60AMENDED SHEET (ARTICLE 19)

Images