Patent Description:
A data pulling operation may involve a user equipment pulling data from a content server via a radio access network.

<CIT> describes systems and methods for <NUM> degree video streaming. A video streaming device is configured to receive a video stream from a network node. It is described that a video streaming device may determine to request a first and second segment of a video stream in advance. The video streaming device may determine a relative priority order for the first and second segment and generate an anticipated requests message. The anticipated requests message may indicate the determined relative priority order of the first and second segment. The anticipated requests message may be sent from a video streaming device to the network node. If a network node receives: a first anticipated requests message from a first video streaming device indicating a first plurality of segments in a first relative priority order; and a second anticipated requests message from a second video streaming device indicating a second plurality of segments in a second relative priority order, the network node may determine that a segment is common and determine a first priority and second priority value for the common segment. The network node may receive the common segment from a server. If the first and second priority values for the common segment are the same, the network node may multicast the common segment to the first and second video streaming devices. If the priority values are different, the network node may unicast the common segment to the first and second video streaming devices.

<CIT> describes a chunk-based scheduling method and apparatus which is implemented on the occurrence of congestion in a wireless communication system. A UE in a network receives details of a configured Available Bit Rate (ABR) bearer supporting chunk-based scheduling. A UE receives a metadata file in relation to traffic data being received by the UE as a streaming service from a server. That metadata file is sent to the UE from an eNB and indicates, via control information, an occurrence of congestion in the network. In response, the UE executes an ABR mode for receiving the traffic via chunk-based scheduling. Thereafter, the UE transmits to the eNB, information (for example, a chunk identifier, chunk size, deadline, and the like) for the next chunk to be received next to the currently received chunk to request chunk based scheduling from the eNB. The eNB performs scheduling such that the chunks to be transmitted to a corresponding UE are transmitted to the UE based on the received deadline.

<CIT> describes apparatus and methods relating to deadline signalling for streaming of media data. A processor at a client device executes a real-time application configured to: determine times during which data will be available for download; determine a time at which data is needed to prevent a buffer underrun for the buffer; and when the data is available, to send a request for the data and deadline information representative of the time at which the data is needed to avoid the buffer underrun. Accordingly, a sending device can prioritise delivery of the requested data to prevent client device buffer underrun. According to a described implementation, after receiving deadline information from the client device, an eNB may schedule transmissions between a content server and the client device per the deadline information. That is to say, the content server may receive a request for media data from a client device and send that media data to the client device via an eNB. The eNB may prioritize delivery of the requested media data to the client device according to deadline information previously received from the client device.

Some examples will now be described in further detail, by way of example only, with reference to the following examples and accompanying drawings, in which:.

The following detailed description focusses, by way of example, on a data pulling operation initiated at a head mounted device (hereafter referred to as HMD-UE) for virtual reality (VR) and/or cross reality (XR) applications, but the technique is equally applicable to data for other types of user equipment and/or for other applications, particularly applications for which the pattern of demand for data is unpredictable, and/or or which a demand for data can be sudden, and for which Time Sensitive Communication Assistance Information (TSCAI) is not best suited to improve scheduling and resource allocation.

The following detailed description focusses, by way of example, on a data pulling operation in a <NUM> NR communication system, but the techniques are also applicable to data pulling operations in other types of communication system.

VR/XR devices, such as a HMD-UE, generally display only a fraction of the omnidirectional 3D scene (i.e., the <NUM>-degree scene around the observer/user). This portion of the space is called Field of View (FoV) or viewport, and its digital representation needs to be downloaded from media storage (MS). The 3D content is spatially divided into independent subpictures or tiles. The content server MS offers multiple representations of the same tile by storing them at different qualities in terms of resolution, compression, and frame rate. The HMD-UE downloads a representation for each tile and decodes it. The download of new XR/VR content may be triggered by an unpredictable event such as a sudden user movement (e.g. head movement), or a need to download the next portion of the 3D video. Once all tiles in the FoV are downloaded, they can be rendered to generate the 3D representation that is displayed to the user.

With reference to <FIG>, a HMD-UE <NUM> pulls data from VR/XR media storage (MS) <NUM> via a radio access network <NUM> and a radio interface between the HMD-UE <NUM> and the radio access network <NUM>.

The different tiles that compose the XR/VR content may be downloaded through independent requests and responses at the application layer. We focus here, by way of example, on requests and responses according to a Hypertext Transfer Protocol (HTTP) protocol. The tiles may received at different time instants by the HMD-UE. However, only when all tiles are available, can the rendering module proceed with the rendering of the whole 3D video in the FoV. The time between a request for new XR/VR content (e.g., initiated by detection of a user head movement) and the time the 3D video is displayed to the user is determined by the time of reception at the HMD-UE of the last one of the tiles that compose the new FoV.

The user (wearer of the HMD-UE) perceives the XR/VR streaming as fluid if the process at the HMD-UE of detecting the head movement, receiving the new XR/VR content and rendering the 3D video is completed within a maximum end-to-end (E2E) latency, which may be called Maximum Presentation Latency (MPL).

In some examples, the MPL is in the order of tens to hundreds of milliseconds (ms), and any extra delay can result in video stalls that affect the user Quality of Experience (QoE).

According to arrangements illustrated in <FIG> and <FIG>, the HMD-UE <NUM> transmits application layer requests (e.g. HTTP requests) for MS <NUM> to send a set of data required for controlling the display output in accordance with a user movement. In addition to the HTTP requests, the HMD-UE <NUM> proactively transmits assistance information for the access network <NUM> so that the access network <NUM> can allocate/schedule resources in a way that meets the delay requirements of the VR/XR application at the HMD-UE <NUM>.

<FIG> illustrates an example of message exchange between the HMD-UE <NUM> and a base station (gNB) <NUM> of a <NUM> NR access network <NUM> and between the gNB <NUM> and the MS <NUM>; and <FIG> illustrates an example of a set of operations at the gNB <NUM>.

During Radio Resource Control (RRC) Connection Setup for the XR/VR session, the HMD-UE <NUM> indicates (STEP <NUM> of <FIG>) a maximum presentation latency (MPL) for the XR/VR session to the access network <NUM> using a Layer <NUM> RRC message. This MPL information is used by the gNB <NUM> for all subsequent sets of requests of the XR/VR session until any new indication from the HMD-UE <NUM> about a change in the MPL.

The gNB <NUM> uses this information about the MPL to allocate/schedule resources for forwarding HTTP responses to the HMD-UE <NUM> from MS <NUM>. In this example, the packets of a XR/VR session can be identified by the access network <NUM> and the XR/VR session is mapped to a specific Quality of Service (QoS) flow, dedicated radio bearer (DRB) and logical channel.

The HMD-UE <NUM> transmits (STEP <NUM> of <FIG>) a sequence of N HTTP requests for the content server MS <NUM> to send a set of tiles needed within the MPL time. Immediately before sending the first HTTP request of the sequence of N HTTP requests, the HMD-UE <NUM> transmits (STEP <NUM> of <FIG>) an indication for the gNB <NUM> of the ID of the HTTP request (r1) and the time when the first HTTP request is generated (t1). For this embodiment and also further embodiments, the ID of the HTTP request may be anything that permits the gNB <NUM> to bind the HTTP request with the corresponding one or more HTTP responses. For example, the ID may be the Uniform Resource Locator (URL) of the XR/VR content that the request relates to (and which is to be returned in one or more HTTP responses), or the ID may be a function of a combination of header fields (such as e.g. a hash function of static header fields). This assistance information is transmitted using a Medium Access Control (MAC) Control Element (CE) or Packet Data Convergence Protocol (PDCP) Control Packet Data Unit (PDU). Alternatively, this indication may be included in the PDCP Header of the PDU containing the <NUM>st HTTP request (r1) as payload.

After receiving this assistance information, the gNB <NUM> starts a MPL countdown timer set to expire after a time equal to the MPL. The gNB <NUM> forwards the HTTP requests to the MS <NUM>, and receives HTTP responses from the MS <NUM> in reply to the HTTP requests. There may be a plurality M of HTTP responses for each of the N HTTP requests. HTTP Res j,i is the i-th HTTP response for the j-th requested tile; wherein i is a value between <NUM> and M and j is a value between <NUM> and N.

As part of the process of forwarding the HTTP responses to the HMD-UE <NUM>, the gNB checks (STEP <NUM> of <FIG>) the value of the MPL countdown timer. Provided the MPL countdown timer has not expired (i.e. provided that the MPL countdown timer value > <NUM>), the gNB <NUM> gives increased scheduling priority to traffic for the XR/VR session to which the MPL relates (including forwarding of the HTTP responses from MS <NUM> to the HMD-UE <NUM>) (STEP 3a of <FIG>), at the expense of background traffic, including downlink (DL) traffic to one or more other UEs served by the gNB. Background traffic is buffered if radio resources are not enough for both forwarding the HTTP responses from the MS <NUM> and the background traffic.

Increasing scheduling priority to the traffic for the XR/VR session to which the MPL relates (including forwarding the HTTP responses to the HMD-UE <NUM>) involves increasing allocated resources (e.g., priority of the logical channel, prioritized bit rate, capacity, radio resources, etc.).

If it happens that the MPL countdown timer has already expired before all HTTP responses for all N HTTP requests have been forwarded to the HMD-UE <NUM>, the gNB <NUM> ceases (STEP 3b of <FIG>) to give maximum priority to XR/VR session to which the MPL relates (including forwarding of HTTP responses for the N HTTP requests related to the MPL countdown timer), on the basis that the delay requirements for the XR/VR application at the HMD-UE <NUM> cannot be met anyway for the VR/XR data carried by those HTTP responses. The assistance information provided (STEP <NUM> of <FIG>) by the HMD-UE <NUM> for the gNB <NUM> also includes an indication of the ID (rN) of the last, Nth HTTP request of the set of N HTTP requests, and the time (tN) at which it was generated. This may be done using a PDCP control PDU or using one or a plurality of reserved bits in the PDCP Header of the PDCP PDU containing the Nth HTTP request as payload. This assistance information enables the gNB <NUM> to identify the last, Nth HTTP message of the exchange related to the MPL countdown timer. This enables the gNB to determine (STEP <NUM> of <FIG>) when all HTTP responses relating to the MPL countdown timer have been transmitted to the HMD-UE <NUM>. This can, for example, help the gNB <NUM> to process two or more XR/VR sessions proceeding in parallel. The gNB <NUM> may use the information about the number N of requests relating to the MPL to control the relative priority given to each of two or more XR/VR sessions proceeding in parallel. Depending on the relative progress of each of the parallel sessions, the gNB <NUM> may prioritize the traffic for one session more than the traffic for another session, based on (a) the respective number of uncompleted requests and (b) the amount of time remaining on the respective MPL timer. For example, with the aim of avoiding missing the MPL for both of two parallel XR/VR sessions, the gNB <NUM> may give selective priority (e.g. maximum priority) to the traffic for the one of the parallel sessions that currently has the best chance of being completed within the MPL, before (if still within the MPL for the other session) then giving maximum priority to traffic for the other XR/VR session. For example, the gNB <NUM> may selectively give maximum priority to traffic for the XR/VR session for which the ratio of (i) current MPL Timer value to (ii) the number of outstanding requests (ratio = Timer/(N-Nf), wherein Nf is the number of responses already forwarded to the HMD-UE <NUM>) is the highest.

In addition, the assistance information <ID,time> related to the first and last (Nth) HTTP requests enables the gNB <NUM> to keep track of the different elements of the experienced round trip time (RTT), namely the upstream and downstream delays on the radio access network <NUM> and the upstream and downstream delays on the backhaul. This information about the experienced RTT can be used, for example, to change the scheduling of resources or to inform the HMD <NUM> to anticipate the download of new content (or to change the MPL).

In summary, providing assistance information for the gNB <NUM> by the HMD-UE <NUM> according to this first embodiment comprises: indicating the Maximum Presentation Latency (MPL), when the XR/VR session is established (and/or whenever MPL changes); and Radio interface signaling (Layer <NUM> signalling) indicating when the first and Nth HTTP Requests are transmitted.

The method according to this first embodiment may be considered to be a proactive method, since the gNB <NUM> schedules traffic to ensure that the MPL is achieved for all tiles of the set of tiles to which the MPL applies, without relying on latency feedback from the HMD-UE <NUM>. The gNB <NUM> can allocate/schedule resources to meet the delay requirements of the VR/XR application at the HMD-UE <NUM>.

According to one example variation of the first embodiment, the HMD-UE <NUM> sends a single HTTP request for all tiles of the set of tiles to which the MPL applies. According to this example variation, the HMD-UE <NUM> (a) transmits a Layer <NUM> (L2) message for the gNB <NUM> (e.g. MAC CE or PDCP Control PDU) indicating when the single HTTP request was generated, and (ii) in response to receiving a tile, transmits a L2 message for the gNB <NUM> (e.g. MAC CE or a PDCP Control PDU) indicating the number of tiles yet to be received. The gNB <NUM> keeps track of the tiles that have been delivered and allocates radio resources to the remaining tiles in order to meet the MPL at the HMD-UE <NUM>.

<FIG> illustrates an example of an exchange of messages between the HMD-UE <NUM> and gNB <NUM> and between the gNB <NUM> and content server MS <NUM>, according to an arrangement. <FIG> illustrates an example of operations at the gNB <NUM> according to that arrangement.

In this arrangement, the HMD-UE <NUM> sends assistance information to the network related to the XR/VR service when one or all tiles have been downloaded. As in the first embodiment, the HMD-UE <NUM> informs the gNB <NUM> of the MPL for the XR/VR session. The information about the MPL can be sent as new capability information in the last Layer <NUM> RRC message transmitted by the HMD-UE <NUM> during the RRC configuration setup procedure for the XR/VR session.

Whenever new XR/VR content needs to be downloaded (e.g., in response to detecting a head movement at the HMD-UE <NUM>), the HMD-UE <NUM> sends one or more HTTP requests for the content server MS <NUM> to download N new tiles. The gNB <NUM> forwards the HTTP request to the MS <NUM>, and the MS <NUM> sends HTTP responses for the HMD-UE <NUM> with the requested tiles embedded therein. A single tile may be in M pieces embedded in respective HTTP responses. For example, a single tile may be a long sequence of images representing a portion of a video stream. The gNB <NUM> forwards the HTTP responses to the HMD-UE <NUM>.

In response to receiving all HTTP responses for a tile (e.g. M HTTP responses for M pieces of the tile), the HMD-UE <NUM> estimates the download latency for the tile, and transmits (STEP <NUM> of <FIG>) an indication for gNB <NUM> of the estimated tile latency. The latency for a tile can be estimated at the HMD-UE <NUM> by starting a count-up timer at the HMD-UE when the HTTP request is generated and stopping the count-up timer when the last, Mth HTTP response for the tile is received. The estimated latency information is communicated to the gNB <NUM> by the HMD-UE <NUM> in the form of a MAC CE or PDCP Control PDU. In the case of using a MAC CE, the corresponding Logical Channel (LCH) and/or Dedicated Radio Bearer (DRB) may also be signaled.

Based on the information received at the gNB <NUM> from the HMD-UE <NUM> about the MPL and based on the estimated latency information for a single tile, the gNB <NUM> controls (STEP <NUM> of <FIG>) the scheduling priority for traffic for the XR/VR session to which the MPL relates (including the forwarding (STEP <NUM> of <FIG>) of the HTTP responses to the HMD-UE <NUM>).

According to one example, radio resources are allocated to the XR/VR service (transmission of HTTP responses from MS) and a fraction α∈<NUM>;1of the background traffic using a round robin scheduling scheme. The remaining <NUM>-α fraction of the background traffic is buffered if radio resources are not sufficient. The value of α is incremented by β = <NUM> up to β = <NUM> every time the HMD-UE <NUM> indicates that an individual tile latency has met a threshold MPL necessary to download all tiles within the MLP, and multiplied by a factor γ < <NUM> (e.g., γ = <NUM>) every time the HMD-UE <NUM> indicates that an individual tile latency has not met the threshold necessary to download all tiles within the MLP. At the beginning the value of α=<NUM>. More generally, at any time t, the value of α (denoted αt) can be set according to the following rule: <MAT>.

The condition can be individual tile latency has met a threshold defined as function of MPL.

The method of this arrangement can be described as a reactive method since the gNB <NUM> controls scheduling priority in response to receiving latency information for a tile from HMD-UE <NUM>. Some tiles might experience different service time. For example, the gNB <NUM> may decide to increase the scheduling priority for later tiles after detecting from the latency information provided by the HMD-UE <NUM> that the latency experienced by earlier tiles is too high to guarantee that all tiles of the set to which the MPL applies are received at the HMD-UE <NUM> within the MPL.

In the arrangement illustrated in <FIG> and <FIG>, the HMD-UE <NUM> indicates (STEP <NUM> of <FIG>) to the gNB <NUM> if a certain latency threshold for a tile is met after receiving all the data for the tile. This information from the HMD-UE <NUM> indicates to the gNB <NUM> whether the individual tile latency is sufficiently low to complete the downloading of all tiles to the HMD-UE <NUM> within the MPL.

The HMD-UE <NUM> may, for example, estimate the latency for the operation of pulling one tile from the MS <NUM> by starting a count-up timer when sending the HTTP request for the tile, and stopping the count-up timer upon reception at the HMD-UE <NUM> of the last HTTP response for the requested tile. The HMD-UE <NUM> estimates the overall download time (time for pulling all tiles from the MS <NUM>, to thereby complete the data pulling operation) by multiplying the latency measured for one tile (value of the count-up timer when it was stopped) by the number of tiles N. If the estimated overall download time is not greater than the MPL, the HMD-UE transmits a positive indication for the gNB <NUM>. If the estimated overall download time is greater than the MPL, the HMD-UE <NUM> transmits a negative indication for the gNB <NUM>.

The gNB <NUM> controls the scheduling priority given to traffic for the XR/VR session to which the MPL relates (including forwarding HTTP responses from the MS <NUM>) according to these indications. The gNB determines whether the individual tile latency indication from the HMD-UE <NUM> is a positive or a negative indication (STEP <NUM> of <FIG>). If the indication is negative, the gNB <NUM> increases (STEP 23a of <FIG>) the scheduling priority for traffic for the XR/VR session (including forwarding (STEP <NUM> of <FIG>) HTTP responses from the MS <NUM>). On the other hand, if the indication is positive, the gNB <NUM> decreases (STEP 23b of <FIG>) the scheduling priority for traffic for the XR/VR session (including forwarding (STEP <NUM> of <FIG>) HTTP responses from the MS <NUM>).

For some arrangements, the HMD-UE <NUM> may report a latency or latency threshold indication for each individual tile, or the HMD-UE <NUM> may only do so for tiles for which the measured individual tile latency is measured to be higher than is necessary to download all tiles (to thereby complete the data pulling operation) within the MPL. This latter option avoids reporting small fluctuations frequently. For example, the HMD-UE <NUM> may indicate to the gNB <NUM> in a single Layer <NUM> message a plurality of tiles for which the individual tile latency is measured to be higher than is necessary to download all tiles within the MPL. The message may include the IDs for the plurality of tiles).

According to one variation of an arrangement, the HMD-UE <NUM> instead transmits for the gNB <NUM> an indication of the variation of the latency. For example, the variation indicated to the gNB <NUM> may be e.g. an indication of whether the individual tile latency of the tile most recently received at the HMD-UE <NUM> was higher or lower than the individual tile latency of the immediately preceding tile. Alternatively, the variation indicated to the gNB <NUM> may be a standard deviation value. This indication for the gNB <NUM> may also be in the form of a MAC CE or PDCP Control PDU. In the case of using MAC CE, the corresponding LCH and/or DRB may also be signalled. The gNB <NUM> determines whether the scheduling priority (thereby the allocated resources) for traffic for the XR/VR session (including forwarding HTTP responses from the MS <NUM>) should be increased or decreased, according
to whether the indication from the HMD-UE <NUM> indicates an increase or decrease in the individual tile latency for the most recently received tile.

The methods of some arrangements are equally applicable regardless of whether a single HTTP request is used for all tiles of the set of tiles, or a sequence of HTTP requests is used for respective tiles of the set of tiles.

In summary, the assistance information provided by the HMD-UE <NUM> to the gNB <NUM> in some arrangements includes: an indication, when the XR/VR session is established (and/or when MPL changes), of the MPL; and an indication of the delay between the HTTP request for a tile and the last HTTP response for the tile, or an indication whether such delay is lower than a threshold calculated to be necessary to download all tiles within the MPL.

The methods of some arrangements may both be considered as reactive methods, because the gNB <NUM> adapts the scheduling priority for traffic for the XR/VR session (including forwarding HTTP responses from the MS <NUM>) in response to indications from the HMD-UE <NUM> of individual tile latency information, to ensure that the MPL is achieved for the whole set of tiles.

<FIG> shows the 3GPP NR user plane protocol stack. The Service Data Adaptation Protocol (SDAP defined in TS <NUM>) is responsible for: mapping of QoS Flow to DRBs. (SDAP marks QoS Flow ID in the packet header as well as QoS which applies to the packet); and the determination of which packets are available at the radio buffers for scheduling as well as configuration of QoS parameters visible to the MAC scheduler.

SDAP determines queue management by enforcing QoS/QoE policies including traffic shaping of lower priority traffic. This allows faster delivery to lower layers of high priority traffic from applications with higher demand (QoS/QoE management).

The QoS Flow is the finest granularity to differentiate traffic forwarding treatment (e.g. scheduling).

QoS Flow may be Guaranteed Bit Rate (GBR) QoS Flow or Non-GBR QoS Flow.

The QoS flow is identified by QoS Flow ID (QFI), dynamically assigned or may be equal to the <NUM> QoS Identifier (5QI). The QoS flow supports reflective QoS.

A QoS Flow is characterized by a QoS profile including: <NUM> QoS Identifier (5QI); and Allocation and Retention Priority (ARP); plus <NUM> QoS characteristics associated with each 5QI scalar: Resource Type (GBR, delay critical GBR or Non-GBR); Priority level; Packet Delay Budget; Packet Error Rate; Averaging window. Maximum Data Burst Volume (for 5QIs with <NUM> Access Network PDB <=<NUM>). For GBR QoS Flow, the QoS profile may also include: Guaranteed/Max. Flow Bit Rate (GFBR/MFBR) UL/DL; Notification control; and Maximum Packet Loss Rate UL/DL. For non-GBR QoS Flow: the QoS profile may include a Reflective QoS Attribute (RQA).

The QoS Flow is also characterized by one or more QoS rule(s).

In the techniques described above, the assistance information provided by the HMD-UE <NUM> for the gNB <NUM> enhances the QoS/QoE mapping of VR/XR traffic at gNB <NUM>.

The above-described arrangements can improve scheduling and resource allocation algorithms at the gNB <NUM> to better prevent stalls and quality loss of XR/VR streams by improving the round-trip-time (RTT) and allocated capacity.

<FIG> illustrates an example of a control apparatus <NUM> for use at the gNB <NUM>. The control apparatus <NUM> may comprise at least one random access memory (RAM) 911a, at least one read only memory (ROM) 911b, at least one processor <NUM>, <NUM> and an input/output interface <NUM>. The at least one processor <NUM>, <NUM> may be coupled to the RAM 911a and the ROM 911b. The at least one processor <NUM>, <NUM> may be configured to execute an appropriate software code <NUM>. The software code <NUM> may for example allow to perform one or more steps to perform one or more of the operations described above The software code <NUM> may be stored in the ROM 911b. The control apparatus <NUM> is interconnected to one or more antenna units (not shown) for making and receiving radio transmissions to the HMD-UE <NUM>, and interconnected to the content server MS <NUM> outside the access network <NUM>. The interconnection with the content server <NUM> may be via one or more other entities (not shown) of the access network <NUM>.

<FIG> illustrates an example of a user equipment <NUM>, such as HMD-UE <NUM> described previously. The user equipment <NUM> may be provided by any device capable of sending and receiving radio signals. In the example described above, the user equipment is a head mounted device (HMD), but the user equipment may be other types of device. Non-limiting examples comprise a hand-held mobile phone or smart phone, a computer provided with a wireless interface card or other wireless interface facility (e.g., USB dongle), a personal data assistant (PDA) or a tablet provided with wireless communication capabilities. The HMD-UE <NUM> may receive signals over an air or radio interface via appropriate apparatus for receiving and may transmit signals via appropriate apparatus for transmitting radio signals.

The HMD-UE <NUM> may be provided with at least one processor <NUM>, at least one memory <NUM> (e.g. ROM and/or RAM) and other possible components for use in software and hardware aided execution of tasks it is designed to perform, including control of access to and communications with access systems and other communication devices. The at least one processor <NUM> is coupled to memory <NUM>. The at least one processor <NUM> may be configured to execute an appropriate software code stored at the memory <NUM>. The software code <NUM> may for example allow to perform one or more of the operations described above. Example functions of the at least one processor <NUM> include: controlling the making of radio transmissions via antenna unit <NUM> (such as the HTTP requests and Layer <NUM>/<NUM> messages mentioned earlier) in response to e.g. input signals from the motion detection unit <NUM>; and controlling the output of the display unit <NUM> based on the input signals from the motion detection unit <NUM> and XR/VR data received from the content server <NUM>.

<FIG> shows a schematic representation of non-volatile memory media 1100a (e.g. computer disc (CD) or digital versatile disc (DVD)) and 1100b (e.g. universal serial bus (USB) memory stick) storing instructions and/or parameters <NUM> which when executed by a processor allow the processor to perform one or more of the steps of the methods described previously.

It is to be noted that embodiments of the present invention may be implemented as circuitry, in software, hardware, application logic or a combination of software, hardware and application logic. In the context of this document, a "computer-readable medium" may be any media or means that can contain, store, communicate, propagate or transport the instructions for use by or in connection with an instruction execution system, apparatus, or device, such as a computer or smart phone, or user equipment.

As used in this application, the term "circuitry" refers to all of the following: (a) hardware- only circuit implementations (such as implementations in only analog and/or digital circuitry) and (b) to combinations of circuits and software (and/or firmware), such as (as applicable): (i) to a combination of processor(s) or (ii) to portions of processor(s)/software (including digital signal processor(s)), software, and memory(ies) that work together to cause an apparatus, such as a mobile phone or server, to perform various functions) and (c) to circuits, such as a microprocessor(s) or a portion of a microprocessor(s), that require software or firmware for operation, even if the software or firmware is not physically present. This definition of 'circuitry' applies to all uses of this term in this application, including in any claims.

The described features, advantages, and characteristics of the invention can be combined insofar encompassed by the scope of the invention as defined by the appended claims. One skilled in the relevant art will recognize that the invention can be practiced without one or more of the specific features or advantages of a particular embodiment as long as it comprises at least every feature of any of the appended independent claims.

Claim 1:
A method, comprising:
receiving at an access network (<NUM>) one or more requests of a data pulling operation initiated at a user equipment (<NUM>) to pull a data set from a content server (<NUM>); wherein the one or more requests comprise a sequence of requests for respective parts of the data set;
forwarding the one or more requests from the user equipment (<NUM>) to the content server (<NUM>);
transmitting for the user equipment (<NUM>) from the access network (<NUM>) a plurality of responses for the sequence of requests for respective parts of the data set from the content server (<NUM>); and
before transmitting all responses for the data pulling operation to the user equipment (<NUM>), receiving assistance information from the user equipment;
wherein the assistance information comprises:
an indication of a maximum useful length of time to assist the access network in managing traffic through the access network such that the data pulling operation is completed within the maximum useful length of time;
an indication to identify the start time of the data pulling operation; and
an indication of an identifier of the first and last requests of the sequence of requests;
wherein the method further comprises:
increasing the priority assigned to traffic related to the data pulling operation by increasing the priority assigned to forwarding responses from the content server until the earliest of:
(a) lapse of the maximum useful length of time since the start time; and
(b) the transmission of responses for all of the sequence of requests of the data pulling operation.